Misc AADS & X9.59 Discussions

AADS Postings and Posting Index, next - home



Storage & Size of certificates
Systemic Risk
IETF PKIX thread on other architectures
A different architecture? (was Re: certificate path
A different architecture? (was Re: certificate path
A different architecture? (was Re: certificate path
A different architecture? (was Re: certificate path
A different architecture? (was Re: certificate path
IETF PKIX CA scaling and SSL
A PKI for the Internet
Complexity and Integrity Issues
more on complexity
Integrity & Availability
Anonymity and Integrity
Identification and Privacy are not Antinomies
comfort certificates
Human Nature
Human Nature
U.S. & Ireland use digital signature
U.S. & Ireland use digital signature
U.S. & Ireland use digital signature
more authentication & authorization
EU digital signature initiative stalled
AADS Strawman
AADS Strawman ... more detail
AADS Strawman ... more detail
AADS Strawman ... more detail
AADS Strawman ... more detail
AADS Activity
On leaving the 56-bit key length limitation
On leaving the 56-bit key length limitation
On leaving the 56-bit key length limitation
On leaving the 56-bit key length limitation
PKI/KRB
digital signatures, technology experiments, and service operations

Storage of Certificates

Refed: **, - **, - **, - **
From: Lynn Wheeler
To: Bill.Campbell@xxxxxxxx
cc: cert-talk@xxxxxxxx, narry@xxxxxxxx, set-discuss@xxxxxxxxmerce.Net
Subject: RE: Storage of Certificates

+----------------------------------------------------------------------+
This message was addressed to:  set-discuss@xxxxxxxx
+----------------------------------------------------------------------+
... as an aside ... in the AADS model for x9.59 it is only necessary to store the public key ... in the CADS model it may or may not be necessary to store the full certificate ... although I do believe that it would be necessary to be able to provide the full, exact certificate on demand; whether that is a generated item or pulled for storage ... i.e. logically a certificate could be stored in compressed form ... starting with a file-system bit compressing methodology ... continuing on down thru application bit compressing methodology ... and then to application information compressing methodology ... i.e. those information components sufficient to regenerate the exact certificate.

Logically file-system bit-compression and application information compression of certificates should be equivalent to outside world ... as long as all were able to exactly render the original.

for related discussion on aads & cads see
http://www.garlic.com/~lynn/
------------------------------------------------------------------------
Brought to you by the CommerceNet Consortium <http://www.commerce.net>,
the premier industry association for companies working together to make
Internet commerce easy, trusted, and ubiquitous.



To: Bill.Campbell@xxxxxxxx
cc: cert-talk@xxxxxxxx, narry@xxxxxxxx, set-discuss@xxxxxxxxmerce.Net
Subject: RE: Storage of Certificates

+----------------------------------------------------------------------+
This message was addressed to:  set-discuss@xxxxxxxx
+----------------------------------------------------------------------+
... oh yes, in the x9.59/aads implementation description ... virtual documents is a form of information compression for passing the necessary information thru backend legacy systems ... and is analogous to information compression for storage of data.
------------------------------------------------------------------------
Brought to you by the CommerceNet Consortium <http://www.commerce.net>,
the premier industry association for companies working together to make
Internet commerce easy, trusted, and ubiquitous.

another characteristic of online validation.

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: IETF-PKIX@xxxxxxxx
Subject: [IETF-PKIX] another characteristic of online validation.
Mack Hicks wrote:
I have to voice my agreement with Mike that cross-certification is not manageable (technical banking term - "scary".))

An example, the trusted relationships between UNIX nodes. One can make the point that the Rhost kind of trust is similar to the cross-certification model. Rhost type of trust has done nothing but get lots of people into lots and lots of trouble.

Cross certification may look OK to field commanders in military applications. Ya know -"Well that's Sam's group - he and I played hockey together - Let's trust those guys."

Some people think banks trust each other through their Am Bnks Ass number (like on the checks). Anyone who has gotten a bounced check knows this is not the case. Knowing the "naming" and "addressing" (name constraints!) does not increase the level of trust.

Keeping naming constraints current - or even manageable - is the full time task for lots of people in the mainframe world. Keeping that trust (usually in one place - like RACF or ACF2) is a full time job that often goes horribly wrong.

So, for financial transactions, we are left with on-line status verification. Is there any bank out there that wants to cross certify? With whom?

-   -    -    -    -    -    -    -    -    -    -    -    -
Mack Hicks (415) 278-7230  -- Interactive Banking Division
425 1st St m/s3671, SF CA 94105 <Mack.Hicks@xxxxxxxx>


another characteristic we've been exploring with x9.59 and aads is the question of systemic risk introduced by inserting a dependency on some other agency when completing a transaction. imagine a financial institution with triple redundant implementation at three harden sites spread around the country ... and now having to go out over the internet and finding some CA operating in somebody's closet in order to complete a transaction. How many people would like to have "whether or not their paycheck got deposited in their bank account" dependent on if a http "hit" was successful or not.

for some of the discussion see http://www.garlic.com/~lynn/

A different architecture? (was Re: certificate path

Refed: **, - **, - **, - **
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: Re: A different architecture? (was Re: certificate path
services [ was RE: NEW Data type for certificate selection ? ])
Many of the infrastructures involving authorization ... include many factors in addition to strong authentication, some real-time and some not. Accont-based infrastructures have been a part of business infrastructures for some time to bind together the necessary information necessary to support authorization. The accont authority digital signature model attempts to integrate public key registration and digital signature authentication into the core business process ... as opposed to working on ways of figuring out what pieces might be exportable to a certificate, then realizing that there are real-time requirements ... which means real-time contact of the CA which is maintaining various critical information.

As the number of attributes are exported into certificates increases ... and the real-time status of those attributes are required to be maintained at the CA for authorization ... a CA would eventually begin to migrate to becoming an accont authority. The current main distinction of a CA is that it is maybe 20-30% handling cryptography for certificates and 70-80% account management. As number of attributes and real-time status requirements increase ... the role of cryptography in the CA becomes smaller and smaller ... and the account management starts to grow to 95+%.

From the financial infrastructure standpoint ... once past toy pilot stage, it is much more cost effective to start with the most robust account-management infrastructure in existance today and retrofit the 1-2% cryptography necessary to support digital signature authentication ... than it is to try and upgrade CAs into business-critical, industrial strength account management support.

A different architecture? (was Re: certificate path

From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: aads & x9.59 (was RE: A different architecture? (was Re:
certificate path services [ was RE: NEW Data type for certificate
  selection ? ])
... X9.59 (built on account authority digital signature model) left financial industiries retail payments committee and on its way for vote as the industry payment protocol standard.

drafts of x9.59 standard are at ansi-epay@xxxxxxxx mailing list archive (also my presentation at NISSC a couple weeks ago). url for the archive and other information on x9.59 and aads is on my personal web site: http://www.garlic.com/~lynn/

A different architecture? (was Re: certificate path

From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: RE: A different architecture? (was Re: certificate path
services [ was RE: NEW Data type for certificate selection ? ])
there are business operations with account-based systems with >100million entries and raw data in tens of terabytes. for business process that have to access the account record to complete the transaction, splitting responsibility for the transaction between an account infrastructure and a PKI infrastructure ... doesn't improve availability ... it actually lowers it since now there has to be two things that are operational for transaction completion i.e. availability to complete is the product of the availability of the two infrastructures; for availability to improve, transaction would have to be able to complete even if the whole PKI infrastructure or the whole account infrastructure was not operational (and since the original premise was that at least the account infrastructure has to be operational for the transaction to complete; adding a PKI infrastructure can't improve the availibitliy)

A different architecture? (was Re: certificate path

From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: RE: A different architecture? (was Re: certificate path
services [ was RE: NEW Data type for certificate selection ? ])
PKI tends to represent a binding between some set of attributes and a public key. Accounts have been used for a long time for attribute binding in business scenerios.

If the PKI attributes start to take on real-time status requirements for various business processes ... then a certificate approach will tend to represent stale status ... and something else must be created to provide real-time status. If business process completion is dependent on obtaining that real-time status ... and some of the status has been PKI linked ... and some of the status is core business process, account-record links ... then availability is impacted (i.e. attribute status like requiring real time information on whether a certificate is even still valid).

A different architecture? (was Re: certificate path

From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: RE: A different architecture? (was Re: certificate path
services [ was RE: NEW Data type for certificate selection ? ])
small note ... from business standpoint ... it might be better explained that no directories no authentication infrastructure (which is the business process/requirement) ... a PKI is then a method of implementing that infrastructure. Part of the problem with starting with PKI as a solution and then asking what the problem is .... one might might be led into presuming that some of the existing PKIs deployed for independent pilots are the structure one would automatically use as an integrated business solution.

directories actually have other business needs independent of the authentication infrastructure. in past life, looked at one customer that had on the order of 6000 RDBMS where 90% of the data was common. schema integration directory was needed just so that simple things like changing the name on an account is consistently done thruout the business (side problem was wide variety of different terms that were used in schemas for common things like name).

A different architecture? (was Re: certificate path

From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: RE: A different architecture? (was Re: certificate path
services [ was RE: NEW Data type for certificate selection ? ])
... and the other serious problem that is starting to show up is the privacy issues related to information that might be in a directory .... even a name field might represent a privacy concern.

Scale (and the SRV record)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: Re: Scale (and the SRV record)
spent a lot of time on the SSL portion of the web ... 94/95 working out how to do/deploy electronic commerce operations. Current SSL infrastructure uses server certificate for key exchange ... not for authentication. To the extent that there is authentication done ... it consists of checking the certificate issuer against a list that has typically pre-installed in the browser (not checking on the certificate owner). It is one of the reasons that I coined the term certificate manufacturing .... to highlight manufacturing and distributing certificates is typically only a small part of what has become to be considered part of a PKI infrastructure.

I got possibly the first mutual authentication SSL deployed ... before it was called SSL3. Again authentication was limited to verifying the certificate issuer. The server certificate was essentially a comfort device for all the clients ... the client certificates started out essentially being "relying party" certificates .... but to do more than simple certificate issuer authenitcation ... i had to check the certificate owner information against an account database. At that point it became evident that even relying party certificates were redundant and superfluous in the transaction since I needed to reference the account record (which already had copy of the public key, lots of attribute binding ... as well as up-to-date real-time status).

A PKI for the Internet (was RE: Scale (and the SRV

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: Re: A PKI for the Internet (was RE: Scale (and the SRV
record))
while the current common certificate infrastructure model is SSL ... which baiscally checks if the certificate has been manufactured by somebody in the list of known certificate manufactures/issuers (aka CAs) .... the common authentication model on the internet is logging on to the service provider.

This one is basically somebody signs up for an account and establishes a password. When they want to use the internet ... they contact the router, give their account name and proof of password. The router is likely running something like radius ... in which case it forwards the account name and password to an account authenticator.

For PKIX to address the most fundamental of internet authentication requirements ... could involve the ISP issuing a relying party certificate with just the account name (sidestepping liability and privacy issues). The choice now would be would the ISP router accept the certificate authentication at face-value ... or would it use a PKI flavor of radius to contact an account authenticator .... for instance to have more timely information on whether the account is in good standing.

This is possibly the most fundamental current internet requirement ... and it illustrates again the extremely short step from relying party certificates to the AADS model ... where if the account has to be touched as part of the authentication/authoritization ... then it is easily shown that shipping the certificate with the transaction is redundant and superfluous (if somebody gives you a copy of something .... how many million times do you have to send the same copy back to them ... before they realize that they don't have to see the copy if they are already looking at the original stored in the account record).

Scale (and the SRV record)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject:  Re: Scale (and the SRV record)
x9.59 attacked different parts of the problem .... in the case of the common useage of SSL for the buy button .... X9.59 was designed to insure the integrity of the financial infrastructure using only digital signature for authentication and not requiring any encryption.

... i.e. while the SSL URL (& certificate) check is interesting ... the common useage for SSL is encryption connection between the client and browser to protect something.

x9.59 insures the integrity of the financial infrastructure w/o requiring SSL/encryption for protection. it has the advantage of doing end-to-end integrity eliminating a lot of the opportunity for fraud (security 101 teaches that any time you separate authentication and authorization .... holes/opportunities for fraud open up). x9.59 also has the advantage that it works for all electronic environments (not simply limited to internet).

one approach to the area that SSL URL checking addresses would be having ISP boundary routers doing address filtering on origin address of incoming packets. this can reduce many of the spoofing related attacks (not just the one caught by the SSL URL checking) and provide some evidence trail back to attack origins. other is general upgrade of authentication procedures to public key ... both at boundary points and infrastructure operations (like DNS).

i believe that public key infrastructure for authentication is good thing. I believe that basic justification for certificates is to provide authentication attribute binding for offline operations; raising offline integrity closer to what online account-based operations have. introducing certificates into an online account-based operations can result in lowering the integrity ....

i.e. online account-based operations with public key authentication (and no certificates) can have extremely high integrity. The incremental increase in integrity offered by certificates would be nominal and typically more than offset by the decrease in integrity created by increased complexity (i.e. complexity all by itself creates an integrity issue). The addition of certificate to an AADS PKI .... would represent an integrity issue .... even if the certificate was totally ignored ... since, at the very least, the level of complexity is raised. To the extent that the certificate is not ignored and represents something in the process .... it further increases complexity (having to check the CA-signing key on the certificate or checking a CRL represents complexity & integrity issues)..... and to actually represent a net increase in integrity there would have to some significant reduction in the account-based operations (like eliminating the account-related operations totally). A troublesome area for the elimination of the account-based operations are real-time attributes and/or sensitive attributes that raise privacy issues.

A pervasive example in the internet world are ISP account based operations for internet service. There are real-time issues like has the account been canceled and/or suspended (for say not paying the bill). One might consider pre-paid accounts (like pre-paid phone cards) ... with a certificate that was good for the pre-paid period. However, accounts still might be cancelled ... which would need reference to the account record. As soon as I have to touch an account record .... then having the public key bound in the account record is simpler and higher integrity than processing information both in the account record and in a certificate (along with all the baggage of validating the certificate & certificate infrastructure).


To: ietf-pkix@xxxxxxxx
Subject: Re: Scale (and the SRV record)
,,,, relying party certificates was something that a european financial institution brought up at NISSC during e-commerce session (issues addressed were business issues associated privacy and liability .... wasn't technical issue regarding size or bandwidth, etc). In discussions afterwards .... the processing flow is almost identical to X9.59 and AADS .... the difference is that one of these certificates flows along with the transaction and gets to the relying party .... where (if they hadn't noticed) they had the original (i.e. client was appending a copy of the certificate to the end of of every transaction sent to the relying pary .... which had the original ... easy to show it was redundant and superfluous).

nissc web site is
http://csrc.nist.gov/nissc/1998/

but there is nothing there on that particular discussion.

They also mentioned an evidence server to validate parts of the infrastructure. That part is also nearly identical to part of an overall infrastructure that i've been presenting for last 8-9 months (which have had included europeans in the audience).

A different architecture? (was Re: certificate path

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: Re: A different architecture? (was Re: certificate path
services was RE: NEW Data type for certificate selection ? ])
in order to complete a transaction/operation ... if a account record has to be accessed at all (because of real-time, privacy or other reasons), then seperating attributes into those in a certificate and those in the account record can, at best, represent redundant and superfluous effort and significant increase in complexity .... and at worst increase various kinds of risk and significantly lower availability of the infrastructure.

there is nothing implicit about partitioning the attributes needed to complete a transaction/operation into several places ... however, each such partitioning typically significantly increases complexity and risk while lowering availability. Reasons for partitioning can include requirements for account-based operations because of things like real-time attributes and/or sensitivity/privacy issues associated with attributes.

the simplest example is an existing online, account-based, electronic authorization environment (say like an ISP RADIUS environment that uses passwords for authentication). Contrast in terms of risk, failure modes, complexity two implementation modes:

1) registering a public key in a RADIUS account record in lieu of a password, modifying the RADIUS serrver to do digital signature authentication with the registered public key, and modifying the RADIUS client to accept a digital signature (in lieu of a password).

2) create a CA, create a CA database, create a CA customer call center and/or tieing an existing customer call center into the CA database, getting a signed CA certificate, registering public keys at the CA, issuing certificates, modifying RADIUS client to accept certificate and digital signature, modifying RADIUS server to verify certificate and authenticate CA digital signature on the certificate, checking for a CRL entry for the certificate, retrieving the CA's digital certificate, verifying the CA's digital certificate and the digital signature on the CA's digital signature, checking for a CRL entry for the CA's digital signature (etc ... possibly on up to the root-CA tree) and finally accessing the RADIUS account record.

First off, the transaction in neither mode will complete if the RADIUS server and RADIUS account record is unavailable. However, in addition, the second mode won't complete if none of the remaining PKI infrastructure is unavailable (and/or if it chooses to continue in spite of it being unavailble opens up fraud and risk potential completing the operation w/o completing the authentication process).

At NISS conference last month a financial institution talked about migration to relying party certificates because of privacy and liability issues .... i.e. a certificate containing only the account number and public key. In this scenerio, the certificate is stored in the account record when the public key is registered and a copy returned to the owner. This about reduces privacy, liability, complexity, risk, availability and fraud exposures to a minimum (associated with using both a certificate and an account record). At this point, the question becomes why does the owner have to send a digital signature and the certificate to the institution on every operation .... if the institution already has the original of the certificate. The downside risk is that the certificate signing key at least becomes a point of attack ... unless the institution totally ignores the sent certificate and alwas relies on the original in the account for verifying the account owners digital signature ... in which case sending the certificate even becomes more redundant and superfluous.

A different architecture? (was Re: certificate path

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: Re: A different architecture? (was Re: certificate path
services was RE: NEW Data type for certificate selection ? ])
there are financial infrastructures that have much higher integrity than any of the CAs or public key infrastructures (i.e. spending past six years getting to the point where there is no down time). When my wife & I were running skunk works in the 80s doing high speed data transport & high availability product ... i coined the term disaster servivability (to distinquish from disaster recovery ... requiring hot operation with geographic seperation).

Part of insuring the integrity of a financial transaction is having access to being able to complete every transaction. Places have gone to the point of guarantee that all information is available in a single place for the completion of the transaction .... bunkering that single place with no-single-point-of-failure iredundancy and UPS with diesel back-up; and then replicating the facility at two additional bunkered sites (any single system at any single site is sufficient to complete the transaction).

Having transaction completion dependency on any offiste data/function lowers the integrity .... availability is the product of all the availability numbers for all things that must be available for the completion .... redundant availability is one minus the product of the non-availability numbers. The financial redundent single site availability number might be five nines (.99999). Triple redendant geographic survivability then would be 1-(.00001*.00001*.00001). Not having all information stored at each site necessary to complete the transaction .... implies that at least two sites have to be operational ... as well as the communication path between them. The financial infrastructure has availability number of 1-(.00001*.00001*.00001). The communication path ... even with diverse routing might be three nines (.999) and the 2nd site mght be four nines (.9999).

The resulting availability for non-single-site-stored-data then is something like:
(1-(.00001*.00001*.00001))*.999*.9999

that can be easily shown to be less than .9999 (since it is the product of numbers that are all less than one ... and at least one of the numbers is .9999 or less) ... which was the original unacceptable number for (at least some) financial infrastructure which prompted the original triple bunkered site with geographic dispersement in the first place.

The alternative model to reach this level of availability w/o requiring geographic redundancy with the single-site data model .... is the simulation of some ECC/FEC possibly R/S 64/80 where all eighty sites have independent failure modes (some mainframe memory subsystems do 64/80 ECC). Small problem is resync'ing sites when some have been offline and their information becomes stale (this is problem in the three site replication also .... but is somewhat easier with three ... than it would be with eighty).

In any case, just saying a CA &/or independent certificate directory has high availability support with no-single-point-of-failure .... doesn't necessarily show the whole scope of the issue. Taking an existing operation that has effectively single-site completion dependency (or even redundnat single-site completion architecture) ... and move to non-single-site completion paradigm ... involves (at least) the local site, the communication modes between the sites, and the 2nd site.

There are also issues of partitioning and locality specific failure modes. An ISP might cover a geographic locality and provides redundancy to handle availability levels up to major geogrpahic specific outages .... but doesn't want to be subject to outages outside local geographic area (i.e. ISP in california would survive everything up to major earthquake in california ... but doesn't have to survive a local major earthquake since all of the customers would be down also). ISPs with geographic locality coverage only has to survive failure modes that the majority of their customers would also survive. National or international ISPs can create gegraphic centered service centers to take advantage of geographic nature of some failure modes. This gets into an area of failure mode management slightly different from the raw statisticaly distribution probability mode of handling failures.

anonymity in current infrastructure

From: Lynn Wheeler
To: micropay@xxxxxxxx
Subject: anonymity in current infrastructure
The financial industry draft standard X9.59 for all account-based retail payments can provide anonymity ... even at point-of-sale environments with the appropriate chipcard. Excerpt from overview at::

http://www.garlic.com/~lynn/aadsover.htm

With the appropriate smartcard, X9.59 can work at point-of-sale, even improving the integrity of the current POS infrastructure, while eliminating the necessity for any identity information in the payment transactions (i.e. no name, address, phone no, etc). With the appropriate smartcard, the account number and the digital signature on the transaction would be sufficient to satisfy high integrity requirements. A combination of the appropriate smartcard, digital signature, and online network provides the financial industry the necessary components to authenticate consumers at retail locations.

Identification and Privacy are not Antinomies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: DIGSIG@xxxxxxxx
Subject: Re: Identification and Privacy are not Antinomies
The X9.59 POS proposal is to use a chip-card to digital sign an X9.59 transaction.

At NISSC 21 in october ... there was a discussion of migration to relying party certificates because of privacy and liabiilty issues. Such a certificate could be as little as the account number and the public key. In some sense, X9.59 extends that even further ... recognizing if the financial institution issued the key-owner a "relying party" certificate .... then the financial institution already has the original ... and therefor it is unnecessary to repeatedly send a copy of the certificate back on ever transaction.

The next stage chip-card then has "on-card" biometrics to verify its owner for purposes of doing a digital signature. The financial instution, as part of registration, keeps track of the hardware environment that houses the digital signing environment and can perform risk assesment based on assurance level.

The X9.59 protocol is the same regardless of whether it is point-of-sale, home web, internet, settop boxes, etc. There can be flexability in the business process and the associated risk assesement based on registring whether or not a chip-card is used for digital signing, the assurance level of the chip-card .... and other factors like if activation requires PIN, on-card biometrics, etc.

In this particular scenerio .... biometrics doesn't represent a privacy issue .... since the card performs the biometrics ... and that information is never exposed outside the card (anymore than the private key .... or if used PIN activation instead ... the card PIN activation value).

In all the scenerios .... the X9.59 bits flowing end-to-end are the same ... its the hardware and the business processes at the end-points that may vary.

Human Nature

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: E-CARM <e-carm@xxxxxxxx>
Subject:  Re: [E-CARM] Human Nature
however as per prior notes ... the idea was to have bodies that already provide "comfort" to consumers in the physical world ... to effectively issue statements/certificates to that fact in the electronic world ... i.e. acquiring banks that have financial liability for purchases at merchants, FDIC which insures deposits at banks, goodhousekeeping which provides some guarantee about purchases, etc. The original statement was about generating comfort certificates w/o having to create any new buisness processes (& KISS).

Human Nature

From: Lynn Wheeler
To: E-CARM <e-carm@xxxxxxxx>
Subject: Re: [E-CARM] Human Nature
.... also many of these comforts cover the whole business operation ... not just whether the web site meets some standard; including getting your money bank even if the company goes bankrupt ... or other issues that have little or nothing to do with a web server operation.

Human Nature

Refed: **, - **, - **, - **
From: Lynn Wheeler
To: E-CARM <e-carm@xxxxxxxx>
Subject: Re: [E-CARM] Human Nature
my orietation/observation is that it is normally less costly to build something from scratch for toy-pilots and/or technology demonstrations than it is to modify an existing infrastructure. However, in the transition to real live business ... there seems frequently to be a cross-over point where it becomes more expensive to create a new business infrastructure to wrapper independent technology tower ... than it would be to modify existing infrastructure.

an optimization is to recognize the cross-over point where the independent towers have reached the limit of the usefullness and it becomes cost-effective to do the business integration.

applied to comfort certificates ... it isn't the issue of the certificates ... but the comfort ... the certificates are some manifestation of that comfort. a consumer's perception of a merchant's web server implementation may be only a trivial piece of the perceived unknowns involved in dealing with a distant merchant that may be in a different country on the other side of the world.

U.S. & Ireland use digital signature

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: DIGSIG@xxxxxxxx
Subject: Re: FW: U.S. & Ireland use digital signature
useful "set" that could use certificates

what i've been calling "comfort" certificates ... issued by acquiring banks (merchant financial institution) to their merchants ... that the merchant can present to consumers (somewhat analogous to the card association stickers you see in merchant windows).

consumers have some level of feeling that the banks stand behind the merchant financially in case of consumer disputes.

for online we could also go with online AADS database for comfort information (analogous to calling up the better business bureau).

this isn't a "default" certificate as people may have been thinking in terms of TTP certification authority ... this is just a certificate that testifies/asserts an existing business process/relationship (between a merchant and the merchant's financial institution).
Since the authentication of the merchant information on the CDROM would be an offline process ... then the solution is a (comfort) merchant certificate on the CDROM i.e. fits my understanding of the original design point for certificates ... providing level of authentication in an offline environment where there would otherwise not be any authentication at all.

This doesn't require certificates for the consumer since while the merchant authentication and the ordering is offline ...the processing of the order by the merchant is assumed to be "online" (in the sense that the merchant would have an online connection to the financial infrastructure).

... and of course more background on AADS & X9.59 at:
http://www.garlic.com/~lynn/

U.S. & Ireland use digital signature

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: DIGSIG@xxxxxxxx
Subject: Re: FW: U.S. & Ireland use digital signature
the highest value for the comfort certificates will tend to be when the consumer otherwise has the least trust/knowledge of the merchant.

internet transactions are quite skewed with the majority of them occuring with a few large merchants. Such large merchants might even be able to get by with self-signed public keys (not even a real certificate) since the consumers will tend to have some amount of trust via other paths (prior experience, word of mouth, advertising, etc).

so while the comfort certificates may apply to the vast majority of merchants (in terms of numbers) ... they will have the most meaning for small percentage of total transactions (since the large merchants representing the majority of the transactions will be accruing trust via other means).

U.S. & Ireland use digital signature

From: Lynn Wheeler
To:      DIGSIG@xxxxxxxx
Subject: Re: FW: U.S. & Ireland use digital signature
as an aside .... it is also dependent on who needs to authenticate what.

in a consumer/merchant electronic commerce ... the merchant isn't really interested in knowing who the person is ... but whether or not the merchant will be paid. In fact, having the merchant identify the consumer actually raises privacy issues. The real issue in x9.59 electronic commerce transaction ... is 1) not revealing identity information because of the privacy issues and 2) not seperating authentication and authorization.

It is not necessary to reveal identity information to merchants ... as long as the merchantsl have some assurance that they will get paid. Having the consumer's financial institution both authenticate and authorize the payment (and notifying the merchants that they will in fact receive funds) ... satisfies a basic security tenent.

In the consumer/merchant retail space ... (near) anonymous transactions preserve privacy for the consumer.

In the more complex business/business space, it is likely that more &/or different due diligence will be required than what is provided by most certification authorities.

The opportunity is finding the set in electronic commerce where default certification is sufficient and at the same time doesn't raise privacy concerns.

Human Nature

Refed: **, - **, - **, - **
From: Lynn Wheeler
To:      "E-CARM" <e-carm@xxxxxxxx>
Subject: Re: [E-CARM] Human Nature
CAs in CADS provide a binding between some set of attributes and a public key. When a subject uses their public key for authentication what trust do relying parties have in the binding of that authentication to the bound attributes?

In AADS, the public key registration also provides a binding between those attributes in the account record and the public key. Third party trust is less of an issue here since the registering party and the relying party tend to be the same.

However, it does bring up another dimension ... the attributes bound in an AADS account record tend to have a direct correlation to the business process (like remaining balance in a bank account); allowing the account record with the digital signature to be sufficient to both authenticate and authorize a digital transaction.

One of the trust issues in business transactions is whether there is sufficient information (regardless of degree of trust) in the CADS model to both authenticate and authorize a transaction (for instance, holding a TTP CA liable if there is insufficient funds to cover a payment/check payment). If there is inadequate and/or stale information in the certificate for acceptable authorization, then the certificate can be inadequate for authorization regardless of the degree of trust). For majority of business transactions the degree of trust may be beside the point if the attributes bound have little or nothing to do with the business process (your checking account balance six months ago may have little to do with whether a check will clear today ... and even worse in the consumer/merchant retail space, the attributes bound may represent privacy issues).

EU digital signature initiative stalled

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: DIGSIG@xxxxxxxx
Subject: Re: EU digital signature initiative stalled
with regard to PKI, heavy infrastructurs, credit-card ... et al .... financial industry has x9.59 draft standard for all account-based payments (debit card, check, atm, crredit, etc) that has digitally signed transactions w/o certificates. also in recent EU discussion about certificate use ... there was comment about eu financial houses using "relying party" certificates because of liability and privacy issue (including some reference that a x509v3 fully identifying individual would represent EU privacy problem in many transactions).

in x9, there was an exercise regarding relying party certificates ... registering a public key with an institution ... the institution creating a relying party certificate, storing the certificate in the account record and sending a copy to the key-pair owner .... then in digital signed account transactions sent to the relying party ... any appending of the certificate to the transaction is redundant and superfluous ... since the relying party will reference the original from the account record (negating the requirment to repeatedly send the certificate copy back on every transaction).

some of the strength of the digital signature relies on the diligence that the registration authority exercise in establishing the attributes bound to the public key (and therefor associated with the digital signature .... whether or not the registration authority makes the business decision to also manufactur a certificate). In the financial industry this frequently translates to risk A trivial fall-out of the non-certificate, account operation is being able to implement parameterised digital signature risk .... for instance proportional to the credit-limit for a specific account. parameters can be software private key environment, hardware token private key environment, assurance level of hardware token housing private key, whether hardware token is pin controlled or biometric contolled, types of attributes bound to the public key, due diligence involved in establishing attributes, etc.

All of these issues regarding process for registering a key and/or environment in which digital signatures take place ... are totally independent of whether a certificate is every manufactured as part of the process. In the X9 standards draft for all account-based payments, it is shown that there is significant benefit for having strongly authenticated digital signature transactions even if an associated certificate has never been manufactured (and even scernerios where using certificates may actually decrease the integrity of the operation).

AADS Strawman

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: e-carm@xxxxxxxx
Subject: [E-CARM] AADS Strawman
Date: 12/09/98 10:11:23 PM
I was at a gathering a couple weeks ago where somebody demo'ed an ISO complient contact card reader that went for something like $2.17. It got me to thinking about why can't a secure chipcard for digital signature be inexpensive and compete with magstrip card.

starting from that premise I've been working on a chip-card strawman that could be ubiquously deployed and supported. It seems like there has been a problem finding a compeling business reason for a chip-card (especially in the US with the low telecom rates) .... and that in search of the compeling business case ... more and more functions are being thrown into chips, apparently in hopes of stumbling across the silver bullet. The downside of this is the increase in chip & support complexity ... driving up the cost and further aggravating the business case problem.

the strawman proposal is looking at taking the opposite approach to result in a compeling business case. The draft X9.59 standard (the only electronic commerce payment standard) relies only on an AADS infrastructure .... requring only a digital signature to support the transactions. In previous AADS postings ... I've hypothesised (see http://www.garlic.com/~lynn/) that a chip-card at the appropriate assurance level could not only be used in the Internet sphere ... but the same card could improve the integrity at point of sale w/o requiring any identification information (i.e. a card that has no name or other identification characteristics).

The strawman characteristics are:
tempested
immune to all known smartcard attacks
pin-activiated (migrating to on-card biometric)
tamper-evident with zeroization
public/private key generated on the card
private key is never divulged
public key can be exported
only function supported is EC/DSS (elliptical curve version of FIPS186)

The objective is to compete in the magstrip card sphere in both price and operation; using existing debit card plastics infrastructure to personalize, record (public) key, mail, and activate card; while still meeting very high integrity requirements. Almost no memory is required (pin, and compact, short ECC public & private key) and very little programming.

The objective is that the card could be used for all AADS operations .... not limited to just AADS X9.59 payment operations ... supporting applications (including all the high-value financial applications) with a (simple) single function. Besides X9.59 AADS operation ... nearly any userid/password infrastructure is converted to AADS by registering the public key in place of the password.

This userid/password translation to AADS can apply to Radius authentication (possibly the dominant method used across the whole internet by ISPs for authenticating their customers connecting to the internet) as well as numerous of the webserver userid/passowrd infrastructures. The simplest webserver scenerio involves keeping the userid in a cookie (much like many systems do today) and replace entering a password with transaction sent to the digital signature strawman.

The strawman chip can be deployed in a privacy-neutral package (i.e. no name, address, identification, etc) and still provide high-integrity transactions using simple digital signature operation (along with owner identification to the card).

The next interesting step is to see if it is possible to accelerate adoption of contactless standard .... allowing the strawman to be deployed in format neutral packaging. In the contactless scenerio, a point-of-sale reader would be able to interact with the strawman chip in almost any packaging:
card
watch
cell phone
ring
PDA

The strawman characteristics then would be privacy neutral, format neutral, high integrity and be simple enough to compete easily with magstripe. Simple, single function along with multiple applications support, including many high-value financial applications greatly simplifies the problem of establishing a compeling business case (ROI equation with a lowered "I" and a raised "R").

The strawman isn't attempting to address the mobile computing infrastructure that some of the efforts are undertaking ... but it isn't precluded from being included in some of the mobile computing solutions, either as separate chip ... or incorporated into a small corner of a much larger chip (becomes the basic strong authentication ubiquous building block).

The infrastructure also lacks systemic risks .... no global secret keys for operation (typical of many of the stored-value operations) and no large numbers of cumbersome data objects all signed with the same private key (typical of the CA-based authentication infrastructures .... which might also include various identity attributes raising privacy concerns).

AADS Strawman

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: e-carm@xxxxxxxx
Subject: [E-CARM] re: AADS Strawman
Date: 12/19/98 09:57:34 PM
chips in magstripe quantities can get very close to the magstripe price point .... somebody several years ago pointed out to me that chips tend to $.10/chip in quantity ... you just have to get on the interesting part of the curve. Also, when you take into account the fully loaded costs of registration, personalization, mailing, and card activation .... the plastic part of the equation tends to get absorbed into all the other costs. Cutting the chip size and complexity by possibly a factor of four helps with the effort.

AADS Strawman

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: e-carm@xxxxxxxx
Subject: [E-CARM] re: AADS Strawman
Date: 12/10/98 11:51:49 PM
Taking it from another standpoint, the AADS strawman is attempting to show cost/benefit of strong authentication function for a large number of business processes .... and do it at very near the magstripe price ... and the asurance level provided to the infrastructure is sufficient to justify its introduction even at a one-for-one swap (ignoring for the moment the possibility of collapsing a large number of existing authentication cards into a single AADS strawman).

The AADS strawman is an strong authentication chip and bears some resemblance to smartcard chips. AADS is looking at the business requirement for strong authentication and the associated value proposition to the business infrastructures of deliverying a cost-effective solution for just that single requirement at the highest possible certified assurance level.

The problem with some of the smartcard solutions in the multi-function arena is that they all seem to significantly increase the cost and complexity compared to the aggresive simplification and volume pricing taken for the AADS strawman .... in addition they impact the certified assurance level of the delivered strong authentication function (complexity testing, various types of contamination issues, introduced viruses, etc).

This isn't a technology in search of a home .... this is a specific set of business requirements for strong authentication and looking at the best price/performance solution for meeting that requirement at the highest possible certified assurance level.

There are a lot of smartcard possible functions .... i just haven't been able to come up with a good reason for co-mingling the smartcard functions in the AADS strawman strong authentication solution.

AADS Strawman

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: e-carm@xxxxxxxx
Subject: [E-CARM] re: AADS Strawman
Date: 12/11/98 08:55:29 AM
  1. dosn't have to be perfect initially .... just has to be significantly better risk proposition than current magstripe
  2. x9.59/aads deploys an infrastructure where the protocol stays the same and it is possible to parmaterize the risk assesement on a transaction by transaction at authorization by recording the assurance level of the card & POS device .... merchants install higher assurance POS ... or consumer upgrades card assurance level ... update the associated account records to reflect the assurance level ... and the authorization process the appropriate thing in the risk assesement of the transaction. remember this is a business solution not a technical solution
  3. not everything has to be perfect day one .... an infrastructure is deployed that doesn't have to change ...... and it is possible to accurately rate the assurance level and therefor parameterize the risk of each transaction as to value of the transaction vis-a-vis the risk & assurance level.
  4. both trusted input (PIN input at point of sale) and trusted output/display (is transaction being signed reflect what is really presented to consumer) can be an issue. On the parameterised risk issue .... it is trivial to do things like knowing MCC of toy store, max. transaction normally done at such MCC, certified assurance level of termianl being used, normal transaction done by card owner, assurance level of hardware housing signing operation. One of the comments about contactless and format neutral ... is that PDA & cell-phone housings can provide owner based trusted input and trusted display ... which can just be reflected in various account records and enter into the risk assesement for transaction.
  5. attacks on the card don't have to impossible ... just 1) attack has to cost significantly more than the value limit allowed for the card/device (part of the parameterised risk) and 2) attack take longer than normal time to report lost/stolen card. Once the card is reported lost/stolen ... that public/private key is invalid and new device is issued. Either and/or both of these significantly reduce the risk & fraud to the infrastructure.
  6. lost/stolen reports, change of address and re-issue become a point of attack on the infrastructure and have to be dealt with
  7. stronger than magstripe and parameterised certified assurance of the devices .... is simpler calculation and improved risk management than some of the neural net stuff done today. POS and signing devices can be incrementally upgraded and just reflected in the parameterised risk calculation.
  8. infrastructure doesn't have systemic risk with global shared-secrets so attack on a single card has to be done within window that card is normally reported lost/stolen. this isn't about the perfect technology ... this is about business requirement and reducing risk &/or better controlling risk ... as well as deploying an infrastructure that can be parameterised and not needing total infrastructure swap in/out when technology changes.

AADS Strawman

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: e-carm@xxxxxxxx
Subject: [E-CARM] re: AADS Strawman
In many respects certificates are electronic analogs of hardcopy licenses and credentials in the offline world. 30 years ago, the credit card industry was using paper booklets of invalid card numbers that were sent out monthly in support of an offline paradigm. The credit card industry made the transition to electronic and the paradigm shift to online all in one step. There could have been the option of distributing electronic analogs of the invalid numbers booklet .... but the shift was made to go both electronic and online at the same time. Instead of doing just the electronic analogy part while keeping the offline paradigm ... the shift was to an online paradigm with online verification (which then eliminated the requirement for invalid lists ... a vestige that is systematic of offline operation).

certificates for the most part are targeted at sitatuions staying with the offline paradigm but upgrading the hardcopy licenses/credentials to electronic.

AADS Activity

From: Lynn Wheeler
To: DIGSIG@xxxxxxxx
Subject: AADS Activity
A new work item is going forward in X9 to standardize AADS ... and another new work item is being proposed to do a XML variation on X9.59/AADS payment protocol

In X9.59 there was a proposal to say something about optional "certificate" support (i.e. a certificate-based PKI-variation in addition to an AADS PKI). There was several institutions that strongly objected on either 1) X9.59 is suppose to be a protocol for all payments in all environments ... not limited to simply internet ... but also supporting point-of-sale ... as a result certificates weren't part of a superset protocol and/or 2) for the internet-specific subset, many institutions felt that they could do a better job with AADS servers ... as opposed to certificates.

Certificates are in some sense electronic analogs to licenses/credentials for offline processing paradigm. Thirty some years ago, credit-card industry was doing monthly mailings of booklets with invalid credit cards. They had the opportunity to go both electronic ... and instead of just simply using electronic analogs of the paper-based world ... they made the shift to electronic and from offline paradigm to online paradigm in one move ... obsoleting the requirement for having electronic analogy invalid booklets by doing online positive authorizations. In a similar fashion, AADS provides an electronic public key infrastructure in an online processing paradigm (instead of just doing electronic analogs, but staying with the offline paradigm).

The awareness of the difference between the offline and online PKI processing paradigms has become even more pronounced in discussions with various credentialing and licensing authorities. In the offline paradigm, the licensing body has no way of knowing the number/amunt and/or type of reliance on the electronic analog. The shift to both electronic and online paradigm has higher upfront expense .... but it has the advantage of being able to track the number and types of references. This becomes especially appealing to various agencies responsible for licensing/credential operations that have direct public/consumer interaction (more than offsetting the additional costs for the online paradigm). Be able to provide the electronic online paradigm service allows them direct contact with the consumer/public they are supposedly serving (in some sense "liability" insurance is a means of highling business processing "bugs" in the offline model).

as another aside ... have updated much of glossary in this area on the garlic pages that i maintain (in addition to the IETF RFC & standard indexing .... also possible to get to garlic from URL point on the RFC Editor's webpages).
Internet RFC1983 -- or just: glossary or taxonomy
Payment -- or just: glossary or taxonomy
Terms merged from: ACH, FACSNET, FRBC, FRBM, FRBSF, GAO, NSCC, and misc.
Financial -- or just: glossary or taxonomy
Warning: Not for light of heart, the combined glossary and taxonomy is nearly 3 megabytes and has been known to lock up some browser versions on some platforms (more because of the number of links than size of files). There are 5000 terms and 6000 definitions. Terms merged from Payment Taxonomy & Glossary with Chicago Board of Trade, C Harvey at Duke (Copyright, for non-commercial use only), MidAmerica Commodity Exchange, New York Merchantile Exchange, New York Stock Exchange, Office Thrift Supervision, Securities Exchange Commission, and Treasury Management Association of Canada
Security -- or just: glossary or taxonomy
Terms merged from: AJP, CC1, CC2, FCv1, FIPS140, IEEE610, ITSEC, Intel, JTC1/SC27/N734, KeyAll, MSC, NCSC/TG004, NIAP, RFC1983, TCSEC, TDI, TNI, and misc
X9F -- or just glossary or taxonomy
Terms merged from X9F document glossaries: WD15782, X509, X9.8, X9.24, X9.31, X9.42, X9.45, X9.49, X9.52, X9.62, X9.65, X9.69.
Terms added from X9F TG-16 glossary document (identified by lower case x9 instead of upper-case X9). Original source documents include: X3.92, X3.106, x9.1, x9.5, x9.6, x9.8, x9.9, x9.17, x9.19, x9.23, x9.24, x9.26, x9.28, x9.30, x9.31, x9.41, x9.42, x9.44, x9.45, x9.49, x9.52, x9.55, x9.57, x9.62, x9.69, x9.xx. (981010)

On leaving the 56-bit key length limitation

Refed: **, - **, - **, - **, - **


SIDE NOTE: The "56-bit key length limitation" discussion somewhat focused on the encryption key-length limitations of the Wassenaar Arrangement


From: Lynn Wheeler
To: ecarm@xxxxxxxx
Subject: Re: [ECARM] On leaving the 56-bit key length limitation
slight digression ... possibly 99% of the use currently is for authentication & integrity ... not privacy .... it is just that keeping information hidden is one way of addressing authentication & integrity. X9.59 electronic payment protocol standard addressed the authentication & integrity issue by requiring digital signature on the transactions with the goal of preserving the integrity of the financial infrastructure with only the digital signature (explicitly seperating the issues of integrity and privacy).

example is that majority of online shopping is done in the clear ... and switch to SSL is done only for providing payment information (i.e. knowing the account number can comprimise the integrity of the infrastructure with fraudulent transactions &/or identity theft). Furthermore ... name and address is used to help authenticate the account number (for things like AVS ... address verification system transaction). X9.59 demonstrates strong authentication on the transaction using only digital signature (not requiring name and address for authentication). As a result, digital signature strong authentication indirectly contributes to privacy by not requiring unecessary privacy information in the transaction.

similarly, primary use in ATM infrastructure is also for integrity.

Transaction digital signature is a generalized solution that can provide end-to-end integrity (which the current information hiding implementations don't do). In theory, In part, current 56-bit protection can be percieved as a weakness because attacks represent integrity attacks. If the infrastructure was changed to digitally signed transaction (ala X9.59) ... and encapsulated inside cloaked channels (solely for privacy concerns) ... the perception of the relative weakness might change (since an attack return-on-investment significantly changes ... with every transaction having end-to-end integrity ... an attack would only yield minimal privacy information ... not any ability to do fraudulant transactions).

On leaving the 56-bit key length limitation

Refed: **, - **, - **
From: Lynn Wheeler
To: ecarm@xxxxxxxx
Subject: Re: [ECARM] On leaving the 56-bit key length limitation
but does WA make a distinction between cryptography for digital signature and cyptography for encryption (&/or information hiding). x9.59 specifically specifies EC-DSS digital signature as sufficient for preserving the integrity of the financial infrastructure (and does not require encryption for integrity).

this is a separate issue from the strength of encryption for information hiding. furthermore, much of the current use of encryption/information hiding is subsumed by digital signed transaction with end-to-end high integrity (i.e. longer key lengths for digital signature for high integrity ... completely orthogonal to the issue of strength of encryption for privacy).

X9.59 using account authority digital signature has the interesting characteristic is the public key (as well as various levels of certificate-based identity information) doesn't ride along on every transaction ... i.e. AADS just has the basic transaction along with the digital signature for end-to-end integrity.

SSL just masks the transaction while in-flight thru the internet .... and doesn't provide any end-to-end integrity.

On leaving the 56-bit key length limitation

From: Lynn Wheeler
To: ecarm@xxxxxxxx
Subject: Re: [ECARM] On leaving the 56-bit key length limitation
in the x9.59 financial infrastructure ... the client/consumer originates a payment instructure and it is operated on by the client/consumer's financial institution. X9.59 provides end-to-end integrity on the payment instruction from the client/consumer all the way thru to the client/consumer's financial institution. The objective was a payment protocol that was to provide end-to-end high integrity applicable for all consumer payments in all environments (internet, atm machines, credit-card, debit-card, point-of-sale, set-top-boxes, etc). From that standpoint, any possible internet component was optional. The objective for X9.59 was to preserve the integrity financial infrastructure for all electronic retail payments (in so far as X9.59 payment transactions were concerned) using digital signature (and not requiring encryption for integrity).

solutions just addressing an internet portion/flavor would have never provided end-to-end integrity for the financial infrastructure

On leaving the 56-bit key length limitation

Refed: **, - **, - **, - **
From: Lynn Wheeler
To: ecarm@xxxxxxxx
Subject: Re: [ECARM] On leaving the 56-bit key length limitation
as specific to internet infrastructure ...there was a thread on the pkix mailing list about the most pervassive & ubiquious internet authentication being userid/password implemented by radius (using by large percentage of ISP for both routers and terminal servers ... from my rfc index:
http://www.garlic.com/~lynn/rfcietff.htm

select Term (term->RFC#) in the RFCs listed by section, and then select "RADIUS" in the Acronym fastpath

part of the thread is at:
http://www.garlic.com/~lynn/aadsm2.htm#scale

proposed draft for AADS

http://www.garlic.com/~lynn/draft-wheeler-ipki-aads-01.txt

I've even heard from at least one place that did a AADS/Radius implementation for ipsec ... to provide the extra degree of authentication timeleness (i.e using existing account management business processes to manage real-time status).

generalized AADS & X9.59 (as well as internet and rfc) standard information can be found at:

http://www.garlic.com/~lynn/

PKI/KRB

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: DIGSIG@xxxxxxxx
Subject: re: PKI/KRB
one of the differences between an AADS PKI and a CADS PI is respect to real time information. The single-sign-on access systems are analogous to door-badge reader access systems ... which come in both offline (aka CADS PKI) and online (aka AADS PKI) varieties. The offline systems tend to be used where there is lower security \concerns and/or lower value. The online systems tend to have more concerns about being able to react to realtime security concerns. Both paradigms are deployed to meet the different business requirements.

Certificates bind public key authentication material to various kinds of attributes, values &/or permissions. Business has been using account records to bind authentication material, attributes and values for eons ... with the advantage that the bindings tend to represent real-time status/information ... not stale information that existing at the time a certificate was manufactured. For business processes that don't have online, real-time requirements, the stale-binding represented by a certificate is satisfactory. Many business have been using account records to serve this purposes for ages .... requiring only that their technology for authentication be upgrading from shared-secret to public key.

It might be useful to remember that at its core, a CADS has an AADS implementation somewhere .... with attributes and other characteristic bindings represented by account record. A CADS has chosen to manufactur a certificate typically for trust propagation capability in infrastructures that currently lack authentication business processes.

Both Radius (dominant authentication, sign-on method used by nearly 100% of the ISPs and corporate installations for PPP remote access (including effectively nearly 100% of home internet & intranet access) as well as Kerberos-base infrastructures are straight-forwardly upgraded to AADS PKI .... effectively the shared-secret field in the account record is upgraded to a public key field.

The original design point for CADS PKI was deployable in offline electronic infrastructures lacking any sort of authentication infrastructure (i.e. like offline email). The objective was to be able to come up with a freestanding infrastructure that would meet the requirements of an environment that was 1) offline and 2) didn't have an existing authentication infrastructure. In the offline email case, the expense of building a new (CADS) authentication infrastructure was justified on the basis of offline email not having an existing authentication infrastructure.

However, for infrastructures that have existing authentication infrastructures, the ease of upgrading the technology in those business processes from shared information/secret paradigm to public key paradigm with AADS is a straight-forward business process upgrade ... not requiring the building of new infrastructures ...

. i.e. in answer to the question ... all other things being equal ... a public-key authentication environment is typically considered to be higher integrity than a shared-secret/information authentication environment. One of the issues would be all other things being equal ... it is relatively straight-forward to demonstrate that for an AADS implementation where existing shared-secret fields are upgraded to public-key. Certificate based infrastructures would at least introduce new business processes that wouldn't provide the same level of real-time control (or if it tries ... it will be a account-based operation making the certificate use redundant and superfluous ... and frequently it isn't the technical minutia that gets you but the business process integration).

somewhat ... total aside ... i spent some time at project athena in the fall of '88 ... and the discussions then of kerberos cross-domain authentication ... sound very similar to some of the cross-domain authentication discussions going on today (and it really is the business processes that can get you).

PKI/KRB original posting:

Dwight Arthur on 04/29/99 02:49:42 PM
To: DIGSIG@xxxxxxxx
Subject:  PKI/KRB

Some time ago we started a discussion on this list about single sign on, and issues were raised about the relative strengths and exposures of public key versus secret key systems for authentication of identity, and subsequent management of authorizations. Some of us have spent some time and many message off of the list working towards a shared vocabulary and a shared understanding of each other's assumptions. Having reached a plateau, I would like to come back to this list with the following observation.

Kerberos, as commonly implemented, relies on a shared-secret for authentication of a user at session initiation. If, instead, a public key system were used, wouldn't the effective security be improved?

<Assumptions>
 <KeyProtection>
Assuming that adequate measures for private key protection were in place
<PasswordStrength>
, specifically including measures to prevent weak or missing passwords
or PINs for accessing the private key
</PasswordStrength>
 </KeyProtection>
<CorroborationOfDN>
, and also assuming that authentication required that the user
demonstrate possession of an authorized key as opposed to just
demonstrating some key which some trusted CA has bound to a DN which
matches the DN of an authorized key
 </CorroborationOfDN>
</Assumptions>
-Dwight

----------------------------------------------
p:(212) 412-8687                 Dwight Arthur
f:(212) 908-2345    Managing Director: Systems
b:(917) 646-6682  National Securities Clearing
dwightarthur@xxxxxxxx    55 Water Street

http://www.nscc.com New York, NY 10041-0082

digital signatures, technology experiments, and service operations

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
To: DIGSIG@xxxxxxxx
Subject: digital signatures, technology experiments, and service operations
One of the things that business appears to be discovering that they will be a AADS digital signature operation regardless of the type of digital signature operation they implement.

Currently there have been a number of digital signature technology expirements that involve
    independent public key registration towers
    stripping the digital signature verification at some network boundary (frequently at some internet boundary) before passing the transaction onto legacy infrastructure for processing.


The interesting thing is that every account-based institution that has looked at migrating from technology experiment involving digital signed transactions to production service has generated work items to perform public key registration.

At a minimum, an account-based sevice operation has a customer care call center that must deal with the account owner. What account-based infrastructures are finding that if they are going to support account-related digitally signed transactions, they will need to register, manage, update, invalidate, etc the account owner's public key (whether naked public key, or public key encapsulated inside a certificate) ... even in technology implementations where the service operation never actually see a digital signature.

In every case that I know of where a large account-based service operation was involved in digital signature technology experiments ... as part of consideration to move to any sort of production service, work items were created to register & support the account-owner's public key in the account-owner's account record. At a minimum, this was a requirement by the serive operation's call center as part of account-owner support. This is totally independent of whether or not any digital signature portion of an account-based transaction is ever directly processed by the service operation.

It is convenient when doing technology experiments to not have to modify/touch production systems. This means not having to do high-integrity support that most large account-based operations implement as well as providing the service aspect typically associated with any account-based operation.

However, when moving to production operation it is significantly less expensive to integrate the digital signature & public key aspects directly into the account-based operation than to try and upgrade the technology experiments to the same level as the production systems. And what is being found, that even if such upgrades are attempting ... that the service organizations of large account-based operations will still duplicate the major portions of a digital signature infrastructure.

For instance, for an AADS infrastructure, the majority of the AADS-related resource costs go to creating the public key field in the account record, registering the public key, managing the public key and having the call center be able to support public key related calls (the remaining portion of actually doing digital signature verification in the account-based legacy processing is trivial compared to managing the public key in the account record). The interesting thing is that large account-based service operations appear to be alwas planning on deploying an AADS infrastructure ... regardless of whether it is an AADS or a CADS signature verification technology that is being used.

This is synergistic with the privacy-mandate direction that is started with relying-party-only certificates for large account-based operations, i.e. if a CADS signature verification technology is involved ... it is with relying-party-only certificates which don't divulge any consumer privacy information. As a result, any associated digitally signed transactions have to involve the account record ... since the RPO certificate doesn't contain any directly usable information. An RPO certificate infrastructure also has the public key registered with the account-record ... which is consistent with other business processes in large account-based operations requiring the public key registration in the account record.

Finally in the X9.59 & AADS scenerio ... it can be shown that the integrity of the transaction is significantly enhanced by directly supporting end-to-end digital signature authentation ... where the agency authorizing/executing the transaction (which includes the use of an account record) also does the digital signature authentication (which can also be done using the public key registered in the account record). This is consistent with the scenerio that the byte-loading weight of the infrastructures carrying many of these transactions are measured in bytes and tens of bytes (making it infeasable to support the transaction carrying weight required by CADS infrastructures ... even in their new compact versions which are still measured in hundreds of bytes).

Large account-based service operations are realizing that they have to support account-base public key registration if they have customers involved in digital-signed account transactions (even in cases where the srevice operation does no direct transaction digital signature verification). It is at least a matter of the service-side of the business ... even if it isn't a matter of the transaction processing side of the business.

AADS Postings and Posting Index, next - home