At 08:15 PM 6/18/2003 -0400, Ian Grigg wrote:
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: TTPs & AADS (part II) OCSP and LDAP An attack on paypal (trivia addenda) An attack on paypal U.S. & Ireland use digital signature Public Key Infrastructure: An Artifact... Public Key Infrastructure: An Artifact... Public Key Infrastructure: An Artifact... Public Key Infrastructure: An Artifact... Public Key Infrastructure: An Artifact... revised Shocking Truth about Digital Signatures Public Key Infrastructure: An Artifact... SSL certs & baby steps FTC says incidence of ID theft jumped in 2002 "SSL & SET Query" ... from usenet group SET; was Re: Why trust root CAs ?
Anne & Lynn Wheeler
Internet trivia 20th anv

--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to