Certificate caching is a far more powerful idea than, say, CA-signed certs. If it were added to browsers, and servers initialised with self- signed certs, then the security of the net would go up immensely. Integrated with some of the ideas that people have suggested concerning WoT, publically distributed certs, and individualised displays (amounting to local secrets keyed on the cert), we could actually start to see people using secured browsing when they wanted to rather than when they were forced to.
typically certificates have had two characteristics .... 1) asn.1 encoding for network interoperability distribution and 2) trusted third party binding of some information to the public key
self-signed certificate caching is really loading public key into a locally maintained table.
in principal there is no need to maintain asn.1 encoding format in a locally maintained table since it eliminates having to decode it on every use .... and the asn.1 encoding is only useful if you 1) are planning on redistributing somebody else's public key and 2) need the original bit format for validating the self-signed signature. The validating of the self-signed signature can be done on initially acquiring the certificate .... and then it can be decoded, and the decoded values loaded into the table. the table/database just becomes entries of public keys and the associated attributes (which might be a combination of the original plus any additional that you might want to add along the way).
in that sense it becomes more of authentication management .... along the lines of kerberos, radius, and/or the AAA RFCs, aka authentication, authorization, and accounting.
in previous posts about BBB, it is possible that it would be used in combination with online trusted references .... i.e. analogous to real-time call to BBB and obtaining referrels and any complaint information ... and then possibly remembering it by recording it in the table (aka online trust propogation as opposed to the offline trust propogation represented by TTP certificates).
Part of the issue with the offline TTP stale, static certificate model was that it periodically tried to overload the contents of the certificate .... trying to justify the expense of the ceritifcate to the public key owner .... but having little or no idea what might be the future requirements of a broad range of relying parties. A locally maintained relying-party table/database would allow the relying party to dynamically adapt the trust characteristics that they were interested in.
Decoding the self-signed certificate before loading into the local table .... helps highlight that the recorded trust characteristics don't have to be restricted to just those that happen to exist in the stale, static certificate (created at some time in the past by entities that had no anticipation regarding your specific trust requirements).
past discussions of online & offline trust propogation:
http://www.garlic.com/~lynn/aadsm12.htm#55 TTPs & AADS (part II)
http://www.garlic.com/~lynn/aadsm13.htm#1 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm14.htm#38 An attack on paypal (trivia addenda)
http://www.garlic.com/~lynn/aadsm14.htm#42 An attack on paypal
http://www.garlic.com/~lynn/aadsm2.htm#useire U.S. & Ireland use digital signature
http://www.garlic.com/~lynn/aadsm4.htm#0 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#2 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#4 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#5 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#7 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsmore.htm#pkiart2 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay11.htm#7 FTC says incidence of ID theft jumped in 2002
http://www.garlic.com/~lynn/aepay3.htm#sslset2 "SSL & SET Query" ... from usenet group
http://www.garlic.com/~lynn/2000f.html#72 SET; was Re: Why trust root CAs ?
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]