Peter Gutmann wrote: > This assumes that the OCSP responder has access to live CA data. Many > responders are fed from CRLs, so you get the illusion of a quick response with > all the drawbacks of a CRL (OCSP was specially designed to be 100% bug- > compatible with CRLs, a much better name for it would be Online CRL-Query > Protocol). As one PKI architect put it, "Being able to determine in 10ms that > a certificate was good as of a week ago and not to expect an update for > another week seems of little, if any, use to our customers". > > Peter.
there was this small client/server startup in menlo park that wanted to payment transactions on their server. http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 that had this thing they called SSL. in the year that we worked with them, they moved from menlo park to mountain view and changed their name from mosiac to netscape (trivial question: who owned the term "netscape" at the time?). as part of doing credit card payments ... we specified that the webservers and the payment gateway had to do mutual authentication (this was before the was any thing like mutual authentication defined in ssl). along the way, we realized that the certificate part was essentially a facade since the payment gateway and the allowable webservers required convential business processes for managing their relationship ... and that having certificates was purely an artifact of the existing code being implemented that way (as opposed to the public key operations relying on more traditional repositories for access to public keys). This was also in the period that we coined the term "certificate manufactoring" to distinquish the prevalent deployment of certificates from the descriptioins of PKIs commoningly found in the literature. The juxtaposition of credit card transactions and PKIs were also startling. The common accepted design point for PKIs were the offline email model from the early 80s ... where the recipient dialed their electronic post office, exchanged email and hung up. They then could be faced with attempting to deal with first time email from total stranger that they had never communicated with before. A certificate filled the role of providing information about total strangers on first contact when there were no other resources available (online or offline ... aka the letters of credit paradigm from sailing ship days). imagine four quadrunts defined by offline/online and electronic/non-electronic. in the 60s, the credit card industry was in the upper left quadrant; offline and non-electronic. They mailed out monthly revokation lists to all registered merchants. With new technology they could have moved into the offline/electronic quardrant (the online/non-electronic quadrant possibly being practical). However, in the 70s, you saw the credit card industry moved directly to the online/quadrant where they had real-time, online authorization of every transaction. In the mid-90s when there were suggestions that the credit card industry could move into the 20 century by doing PKI, certificate-based transactions ... I got to repeatedly point out that would represent regressing the credit card transaction state of the art by 20-30 years ... back to the non-electronic archaic days of offline transactions and the mailed revokation booklets. It was sometime after having repeatedly pointed out how archaic the whole PKI & CRL paradigm actually was that OCSP showed up on the scene (when real-time, online facilities are actually available). It is somewhat a rube-goldberg fabrication that attempts to gain some of the appearance of having modern, online, real-time transactions ... while trying to preserve the fiction that certificates (from the offline & electronic guardrant) are even necessary. The problem is that the original design point for PKI, CRLs, etc .... the offline & electronic guardrant is rapidly disappearing in the always on, ubiquitous internet connected environment. The other market niche that PKIs, CRLs, etc have sometimes attempt to carve out for themselves has been the no-value transaction sector ... where the value of the transaction is not sufficient to justify the (rapidly decreasing) cost of an online transaction. The problem with trying to make a position in the no-value transaction market ... is that it is difficult to justify spending any money on CAs, PKIs, certificates, etc. some amount of past posts on SSL certificates http://www.garlic.com/~lynn/subpubkey.html#sslcert Another facet of the SSL certificate market has to do with SSL domain name server certificates (probably the most prevaling use). One of the justifications for SSL domain name server certificates were concerns about the integrity of the domain name infrastructure. So browsers were setup that would check the domain name in a typed in URL against the URL in a server certificate. The business scenario has a certificate applicate going to a certificate authority (CA) to apply for an SSL domain name server certificate. They supply a bunch of identification ... and the certification authority then attempts the expensive, complex and error-prone process of validating the supplied identification information with the domain name owner identification information on file with the authoritative agency that is responsible for domain name ownership (aka the domain name infrastructure). Now it turns out that the integrity concerns with the domain name infrastructure can extend to the domain name owner information on file ... putting any certification process by a certification authority (for ssl domain name certificates) at serious risk. So somewhat from the certification authority industry, there is a proposal that when people get domain names, they register a public key. All future communication with the domain name infrastructure is then digital signed and verified with the onfile public key (purpose is to improve the overall integrity of the domain name infrastructure). SSl certificate applicants can also digital sign their SSL certificate applications to a certification authority. The certification authority can retrieve the onfile public key (from the domain name infrastructure) to verify the digital signature on the application which turns a complex, expensive, and error-prone identification process into a much simpler, less expensive, and reliable authentication process. However, there is a couple catch-22s for the PKI industry. First, improving the integrity of domain name infrastructure medicates some of the original justification for having SSL domain name certificates. Also, if the certificate authority can build the trust basis for their whole operation on the onfile public keys at the domain name infrastructure ... it is possible others might realize that they could also do real-time retrieval of onfile public keys as part of the SSL protocol ... im place of relying on certficate-based public keys. _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
