Perry E. Metzger wrote: > By the way, I note as an aside that this also means (in my opinion) > that certificates are no longer an interesting technology for > payments protocols, because in a purely online environment, you > never need a third party x.509 certificate in the course of the > payments protocol itself when there are no offline components of the > protocol and all relationships are bilateral.
my impression of the 3party x.509 identity certificate model of the early 90s ... was that every person would pay $100/annum for their identity certificate grossly overloaded with personal information. the certificate model has a design point from the early 80s, offline email, where the receiver dials their local (electronic) postoffice, exchanges email and hangs up. they then are faced with dealing with first time email from total strangers. the x.509 identity certificates, grossly overloaded with personal information ... were targeted at (hopefully) including at least one piece of personal information (about the sender), that the receiver might find useful when dealing with total stranger. moving into the early 90s, with a model where everybody would have $100/annum identity certificates ... the apparent business model would be that all established business relationships would be done away with ... and people would only be performing spontaneous business transactions with total strangers ... supported by the x.509 identity certificates. For instance, rather than depositing money in an established bank account .... you would spontaneously contact a total stranger to accept your large sums of money. The exchange of x.509 identity certificates with total strangers would provide sufficient trust and integrity to safegard your large sums of money. Moving into the mid-90s, some institutions started to realize that such x.509 identity certificates represented huge privacy and liability issues and there was some implementations by financial institutions of relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo which only contained a public key and some sort of database lookup index (as unique information) along with a lot of CPS and other types of certification accounting gorp. In this situation, it was trivial to show that such relying-party-only certificates were redundant and superfluous: the relying party already has all the necessary information on file, which invalidates the certificate design point of providing "letters of credit" type of information between two strangers in first time communicate (where there is no other recourse for information about the party you are dealing with). of course, there was a side issue in these payment protocols from the period. the typical iso8583 payment message is on the order of 60-80 bytes. the typical overhead for even the relying-party-only certificates (attached to every payment message) was on the order of 4k-12k bytes ... leading to an enormous payload bloat of one hundred times for something that was totally redundant and superfluous. In general, the design point of x.509 identity certificates were to turn all transactions (regardless of kind, even the most lightweight authentication transactions) into heavyweight identification operations. You would even find some govs. passing legislation that was oriented towards mandating x.509 identity certificate be appended to every digital signed transaction ... even when you might be looking at purely a lightweight "something you have" authentication operation. misc. recent posts on the subject: http://www.garlic.com/~lynn/aadsm18.htm#29 EMV cards as identity cards http://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning http://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand http://www.garlic.com/~lynn/2005i.html#21 The Worth of Verisign's Brand --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]