the repeated claim in this (and other threads) is that X9.59 eliminates secrecy as requirement to guarentee the integrity of the financial infrastructure (the requirement given the X9A10 working group for the X9.59 standard for all electronic retail payments).
the authentication requirement with x9.59 turns all retail payments into authenticated transactions, eliminates any requirement for any identification information and removes the characteristics of the account number from being a shared-secret (i.e. the account number is currently has the status of a shared-secret, since just by learning the account-number it is possible to execute fraudulent transactions). The business process issues are 1) is authentication or identification required (as per the original subject line). this can be carefully considered. using the same basic technology, it is fundamentally possible to implement either. it is not an either/or possibility. the government could choose to reliably make your digital signature equivalent to your identity. that is a government and business process choice. however, it is not intrinsicly part of digital signatures. It is possible to create a digital signature infrastructure and protocols that are agnostic to whether the government has created an infrastructure making digital signatures and identity equivalent. The issue that the original subject line highlighted is that frequently the technology of authentication and the implementation choice regarding authentication vis-a-vis identification can be grossly confused and lead to inappropriate implementations. This is one of the reasons that most institutions backed away from the original x.509 identification certificate paradigm, the inclusion of huge amounts of privacy information and indescrimently spraying it all over the world was concluded to not be a good thing. 2) certification is basically a business process that is independent of whether it is deployed as a online process (with online transactions) or manufactoring a stale, static certificate at some time in the past as part of an offline paradigm. The certification body and business reliance can be exactly the same in both cases. The difference is whether the relying-party relies on a stale, static certificate or relies on a real-time, online transaction. It can be trivially shown that in almost all cases the online, realtime responses is both higher quality and more valuable than reliance on stale, static certificates. The absolutely worst case scenario is that the high quality, realtime response is the same as stale, static certificates. So one issue, is does the business justificy the cost of the higher quality operation with an online, realtime response vis-a-vis the possibly lower cost of the stale, static certificate information. Certificates were original targeted in the early '80s when there was not ubiquitous, inexpensive, easily available online infrastructure. As the alternative to having no certification (having NOTHING), certificates were better than NOTHING. However, the trade-off has significantly changed during the technologies of the later 90s with the penetration of inexpensive, ubiquitous, pervasive online infrastructure. This is essentially the transition that the online financial infrastructure made in the '70s. In numerous past discussions, it turned out that many of the issues with a global infrastructure didn't truely require identification, but it was sufficient for the specific business processes that strong authentication was sufficient and identification was mostly unrelated. For instance, it isn't necessary for all parties even remotely involved in a financial transaction to absolutely know who you are (aka identification) if strong authentication is sufficient to establish that you are the entity entitled to withdraw funds from a specific account (authentication). In fact, one of the additional inducements for financial institutions to retrench to relying-party-only certificates with absolutely no identification information was an EU directive that said that retail electronic transactions should be as anonymous as cash; specifically that at the point of sale, the retail financial transaction needed to be agnostic with respect to identity. That didn't preclude the government from creating some identification procedure but it did direct that the actual financial transaction was agnostic with respect to identify. As per the original subject line, authentication is about determining is the entity entitled to perform the operation .... without necessarily requiring that the entity also be identified. It doesn't necessarily preclude there being some process for establishing identification, the authentication process can be agnostic with respect to identification. There are large groups of people on both sides of the argument with regard to having authentication processes that absolutely prevent any identification vis-a-vis the authentication process doesn't preclude establishing identification under specific guidelines. When given a requirement to guarentee transaction integrity, strong authentication is sufficient and KISS to meet the requirement. Again that is the original subject line; confusing authentication and identification. However, the issue of offline, stale, static certificates as a certification business process mechanism vis-a-vis online realtime (account-based) certification is totally orthogonal to authentication vis-a-vis identification issues. The business issue for authorizing a transaction in conjunction with an authentication mechanism does come into play a little. I've frequently facetiously referred to an authentication retail store; you walk in authenticate (or even possibly identify) yourself and walk in. The purpose of the retail store is not to actual sell anything, it solely does authentication (possibly identification) operations. This is opposed to retail stores that are there to sell some item, authentication only comes into play when performing a financial transaction (as part of paying for an item to buy). There is nothing that is intrinsicly part of the run-of-the-mill financial retail transaction that mandates identification (there may be other aspects of some retail transactions that mandate identification, but with regard to integrity of the financial transaction, strong authentication is sufficient). Now, each one of these environments tend to have a specific business context which can be taken into account with regard to an online, realtime certification. The certification authority can examine what is the context of the business process and make the appropriate authentication with respect to that context; aka rights regarding logging as a specific userid, rights to doing financial transactions on a specific account, etc. There could be possibly hundreds of contexts that an online, realtime certification authority could be agile enough to adapt to. The issue with a stale, static certificates that are manufactored at some time in the past with little or no fore-knowledge as to the business contexts is quite a bit more problematic. There are basically three choices 1) relying-party specific certificates, one for each possible business context, each one providing the specific authentication context (i.e. is the entity entitled to perform that specific operation). 2) we periodically run across things jokingly referred to as GBD ... Great Big Database in the sky ... the mother of all databases that contains all possible pieces of information. This is a certificate that contains the necessary authentication information for every possible business context (is the entity entitled to do the specific operation in every individual business context). 3) switch from an authentication (whether or not the entity is entitled to perform the operation) paradigm to an identification paradigm. The assumption is that all validly identified individuals are entitled to do everything, possibly a log is made of their activities and there is some settlement made by the government at the end of the month (or at some other interval). It then isn't necessary to provide all possible authentications for every possible business context. Everybody, once identified, are automatically entitled. The stale, static certificate is then reduced from having to serve any authentication purpose and is just relegated to only having to perform an identification role. Trying to establish the value of a PKI stale, static certificate-based operation gets into this muddle. Huge numbers of certificates, one for each context means that the individual value of any specific certificate is significantly depreciated. A single stale, static humongous GBC (great big certificate in the skly) gets to become unwieldily having all necessary information for authentication in all possible business contexts (aka whether the entity is entitled to perform the operation). The GBC is also likely to represent more in business costs than can ever be recovered in certificate pricing. So it quickly comes down to that any sort of major PKI infrastructure is pretty much stuck with an identification paradigm. It isn't so much a business characteristic of certification (which i've repeatedly asserted is totally independent of whether it operates as offline, stale, static certificate, or a realtime, online, certificateless operation). Any major effort at PKI with stale, static certificates pretty much concludes in the identification model (aka #3 above). It is basically what the x.509 identification certificate scenario arrived at in the '80s and the early '90s (effectively because of the considerations outlined above). It is also what was rejected in the mid to late '90s because of the serious privacy issues involved in making a ubiquitous transition from predominately authentication paradigms to a identification only paradigm. The identification only scenario then still faces the serious business quandary of whether an entity is actually entitled to perform the specific operations in the specific context (independent of identification). GLB, HIPPA and other privacy-related legislation is also turning identification into more and more of a business expense. Finally, in normal business, there is a relationship between the provider of something and the purchaser of something. The typical PKI business model is almost a total violation of any existing infrastructure. In all of the online models, the relying party directly pays the certification agency for the online, realtime certification response. There is a valid, direct business relationship between the relying party and the online certification agency. Tbis gets to be really horrible in the traditional, static, stale certificate scenario. The business relationship is between the PKI and the public key owner that purchases the certificate. There is no exchange of value between the certification authority and the relying-party which would be the basis for a normal accepted business process. In the normal accepted business model today involving a public key owner purchased certificate, there is no exchange of value between the relying party and the certification body, and therefor there would normally be absolutely no recourse for the relying party (based on anything the certification body did or didn't do). So the traditional PKI paradigm with stale, static certificates left over from the offline paradigm is faced with: 1) significant transition throughout the world from an offline environment to a nearly ubiquitous online environment 2) the whole rejection of x.509 identity oriented stale, static certificates in the mid 90s because of serious privacy concerns. 3) difficult to create any value proposition for a stale, static certificate since there is no business relationship between the relying party and the certification body (the certificate isn't for the benefit of the certificate owner, it is for the benefit of the relying party .... however the relying party that would benefit, isn't paying and therefor under normal business relationships has no recourse to whether the certified information is valid or not). So the next muddle is since that it really is difficult to establish a viable business model .... turn it into a governement provided identification service. In some sense this isn't an authentication requirement, which can be handled perfectly validly with an online paradigm and suffers none of the shortcomings of a stale, static certificate paradigm. In some sense, it is a extension of the line of thought that (stale, static) "Certificates Are The Answer" and the government provided identification service might appear to be the only viable way to create a role for certificates. 1) Governments can mandate things and totally ignore issues like the world transitioning to an ubiquitous online environment. 2) Governments can madate things and totally rewrite what are acceptable privacy guidelines and what are not. 3) Governments can mandate things and totally dictate what relying parties will accept. So lets say we have a government mandated provided identification service based on stale, static certificates. As outlined in the previous post: http://www.garlic.com/~lynn/aepay11.htm#72 Account Numbers. Was: Confusing Authentication and Identification? (addenda) we have the case of doing ISP login using digital signatures. With the stale, static certificate model, the router on receving the triple (login transaction, digital signature, certificate) should have all the necessary and sufficient information to establish the login operation. The certificate gets validated as a valid, government identification certificate and the public key from the certificate validates the digital sginature; voila the person is connected w/o needing to find out if the entity is entitiled or not (authentication). There is absolutely no requirement for authentication since the government identification certificate is sufficient for establish the right for service. So we are led into this muddle that now has both 1) giveronment identification stale, static certificates, and a government identification stale, 2) static certificate is sufficient for authorizing all operations w/o requiring any additional effort. Now, unless we have created a totally government supplied world for all possible services; there typically are business entities and they establish some sort of business operation for services or products. Today these business relationships are represented by account records. People having contracted for ISP internet service have a RADIUS account record. The logical account record (which may be partitioned into several physical records) typically contains the T&Cs of the business relationship as well as the necessary information to authenticate the entity that is entitiled to use the contracted for service. In the traditional business authentication-based scenario, the entity creates a login transaction with the appropriate authentication information (which I assert can be a digital signature) and the double (aka transaction plus digital signature; not the triple as in the stale, static certificate based scenario) is transmitted. The receiving router gets the username (or other) handle and retrieves the corresponding RADIUS record. The transaction is authenticated with the information in the RADIUS record and then the rest of the information from the RADIUS record indicates the entitled to service. Lack of the appropriate RADIUS record or lack of authentication is an endication that the requesting entity has not contracted for the requested service. In the offline, stale, static identification certificate scenario, it is sufficient to identify the requesting entity, it isn't actually necessary to establishing that the requesting entity is entitled to the requested service (or is entitled to the explicit or implicit permissions). so back to the original subject line about confusing authentication and identification: http://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and Identiification? http://www.garlic.com/~lynn/aepay11.htm#67 Confusing Authentication and Identiification? http://www.garlic.com/~lynn/aepay11.htm#68 Confusing Authentication and Identiification? http://www.garlic.com/~lynn/aepay11.htm#69 Confusing Authentication and Identiification? http://www.garlic.com/~lynn/aepay11.htm#70 Confusing Authentication and Identiification? (addenda) http://www.garlic.com/~lynn/aepay11.htm#71 Account Numbers. Was: Confusing Authentication and Identiification? (addenda) -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm [EMAIL PROTECTED] on 6/26/2003 12:31 pm wrote: In the purest sense, an individual is a discrete entity and why should their identifier be a topic of discussion? In every advanced country we already have a name and a government-maintained UID. The financial industry (and others) needs to end their reliance on secrecy of the UID and associated information per se. I am uneasy with Lynn's criticism of "stale" digital credentials, since, how else is the individual ever to achieve the capability to identify ourselves over networks? At times I feel the internet may be truly, fundamentally useless until there is a global and publicly accessible registry of individuals and their public keys. As parties are not strongly identified then, communication about things of consequence is proving to be impractical. Everywhere I look, I see large efforts and investments at the server side, to garner some profit for (increasingly larger) central hosts. I see nothing intended to give the economic benefits of the global internet to individuals or endpoints on the internet. With great reluctance I am beginning to agree with the European governments' notions of providing a PKI for their citizens. In the US, I believe it would be a good thing if the federal government maintained a network interface where anybody could submit a SSN, and receive in return, the name, address, and public key of the individual. Todd
