On 08/06/09 07:33, James A. Donald wrote:
The fundamental problem with certificates is getting them.
digital certificate design point supposedly was the dial-up email of the early 80s, dial-up, exchange email, hang-up ... and then faced with how to deal with first time email from complete stranger. basically electronic analog for letters of credit/introduction from sailing ship days. in the 90s, because of numerous privacy and liability issues ... there was some number of "relying-party only" certificates; individual registered their public key with the institution, institution then created a digital certificate with the public key, archived it, and returned a copy to the individual. the individual, in communication with the institution would digitally sign the communication and then append the digital certificate. However, it was trivial to prove that the institution/relying-party already had a copy of the information ... and the appended digital certificate was redundant and superfluous. misc. past posts discussion relying-party only digital certificates http://www.garlic.com/~lynn/subpubkey.html#rpo furthermore, major foreys into this sector were by financial institutions for the purpose of payment transactions. a complicating factor ... besides the digital certificates being redundant and superfluous ... they added a 100 times payload size bloat to the typical payment transactions. misc. past posts http://www.garlic.com/~lynn/subpubkey.html#bloat there was a financial standards effort that looked at possibly doing "compressed" digital certificates (trying to achieve only ten times bloat) ... eliminating redundant fields and information already in the possession of the individual's financial institution. we showed that the individual's financial institution already had superset of the information in the digital certificate ... so it was possible to compress digital certificates to zero bytes ... and then mandate that financial transactions would always have zero-byte certificates appended (as opposed to no appended digital certificate). Something similar was demonstrated for RADIUS and Kerberos ... registering a public key in lieu of password ... some past references http://www.garlic.com/~lynn/subpubkey.html#radius and http://www.garlic.com/~lynn/subpubkey.html#kerberos and also something similar for registering public key with domain name registration with domain name infrastructure ... for use in lieu of SSL digital certificates http://www.garlic.com/~lynn/subpubkey.html#catch22 that left institutions and relying party with no-value business processes as digital certificate opportunities ... i.e. no-value transactions where the relying party couldn't justify the cost of their own entity repository and/or justify the cost of doing an online transactions to obtain such entity information ... and of course ... the original design point, the "offline email" scenario with first time communication with complete strangers. One of the problems with no-value market segment is that it is hard for institutions and individuals to justify paying for things without any value ... and therefor it is hard to find entities looking at selling things for nothing. -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com