The original design point for (identification) certificates ... was offline email ... aka, connect, exchange email, hangup ... process all email offline. Relying-party/enduser is sitting there with no online connectivity and some need to authenticate originator of the email.
The payment transaction industry in the '60s was an offline, hard-copy operation. They could have gone thru the technology stage compareable to certificate paradigm ... by going to electronic and offline ... but they actually stepped that intermediate step and moved all the way to electronic and online starting in the '70s. Various of the payment related activities associated with certificates in the '90s was a technology step backwards .... to an electronic & offline paradigm ... something that the payment transaction business had skipped over in the '70s. So in the 90s, the payment transaction business has an online & electronic infrastructure ... and various certificate factions were trying to introduce the concept of a 20 year technology regression with the suggestion for an electronic and offline paradigm ... rather than the more modern online and electronic paradigm that they had been using for 20 years. One of the places that financial institutions attempted to extend this is somewhat typified by the FSTC "FAST" project. The financial industry already has a modern online & electronic authentication and authorization infrastructure instantiated by the payment transaction network. FAST essentially abstracted that modern online & electronic paradigm from being a payment only infrastructure to a generalized authentication and authorization operation. Basically, the end-user makes an assertion and signs it and gives it to the relying party. The relying party (say merchant) does a real-time, online, electronic transaction sending the assertion to the end-users financial institutioin ... and the financial institution can return a real-time, online electronic message as to the validity of the assertion. Currently the assertions are only about amount of money to pay ... but FAST extended the modern, online, electronic authorization/authentication paradigm to be just about any information. One of the big advantages of FAST (besides being modern, online, electronic .... rather than old-fashioned offline, electronic paradigm that the financial industry had decided to skip 30 years ago) was that it minimized privacy and indenty information leakage. There wasn't a general purpose identity certification that had a catch all collection of privacy information that somebody, someplace might be interested it. An assertion could be something specific like "over 21" or "over 18" ... or "under 18", .... some assertion that was specific to business process at hand. The other characteristic was that even in the scenarios where some certificate was forced-fit into such an operation .... they were reduced specifically to relying-party-only certificates .... one of the primary reasons was the big issue of identify & privacy leakage represented by a typical x.509 identity certificate. The relying-party-only certificate was reduced to simply an account number and a public key ... in large part to avoid the privacy exposures. However, a relying-party-only certificate can trivially be shown to be redundant and superfulous since everything that is in the relying-party-only certificate is already replicated in other parts of the business process. In part, this is another demonstration that trying to force fit a offline/electronic solution into the world of real-time, online, electronic environment ... stands out like a boil on the side. random refs: http://www.garlic.com/~lynn/subtopic.html#privacy Another way of viewing the sitution ... is from the standpoint of the fundamental business process components. The typical RP in a transaction ... isn't directly about what the consumer/end-user has to say ... it is concerned about what the financial institution has to say. If it is a merchant ... the merchant is insterested in having a real-time response from the financial institution about whether the merchant is going to be paid or not. There is a timeliness associated with that answer .... that is impossible to get in a certificate electronic/offline paradigm. [EMAIL PROTECTED] on 11/12/2002 8:21 am wrote: Survey regarding the future of PKI trust networks ------------------------------------------------------ Traditionally certificates have been purchased (or just issued) for an entity by a party that is concerned that the entity can be properly identified in authentication- and signature-operations. For a relying party (RP) to check certificate-status has mostly been a public and free service. The financial industry however, have in several recent PKI-ventures shown that they intend to change this by treating lookup-services as equivalent to payment transactions, where the RP's bank is used as a "trust clearing center" communicating with the subscriber's bank that must be a member of the same "trust network". To make it technically impossible for RPs to fully verify signatures without going through the trust network (and paying for the services), root-certificates are usually not "published". I would be very happy to hear what the PKI community in general think about this scheme as the future for PKI. Off-list responses will be treated as CONFIDENTIAL information. Anders Rundgren
