James A. Donald wrote: > PKI's deployment to identify ssl servers is near one > hundred percent. PKI's deployment to sign and secure > email, and to identify users, is near zero and seems > unlikely to change. PGP has substantially superior > penetration.
PKI deployment to authenticate SSL servers almost doesn't exist. we were called in to work with this small client/server startup that wanted to do payments on their server ... and had this technology called SSL. we had to do a lot of laying out the business ground work for the payment stuff ... and because they wanted to use SSL for pieces of it and certification authorities issuing digital certificates were involved ... we also had to go audit the major digital certificate issuing institutions. http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 in the course of doing this ... we coined the term "certificate manufactoring" to describe what we were finding ... as one way of differentiating it from the industry accepted definition for PKI. http://www.garlic.com/~lynn/subpubkey.html#sslcert another place that it came up ... was that we had a SSL encrypted session defined between webservers (doing payment transactions) and the payment gateway. special digital certificates were issued for both the webservers and the payment gateway as part of initializing the encrypted tunnel (and we forced the implementation of mutual authentication ... rather than the simple one-way that was available at the time). At this point it became readily apparent that the digital certificates part of all this were redundant and superfluous. All the webservers had the public key of the payment gateway pre-installed in the webserver ... and the payment gateway had a separate mechanism (once the encrypted tunnel was set up) for authenticating the webserver (based on established payment processing conventions). while there was movement of digital certificates during the setup of this encrypted tunnel ... it was purely an artificial artifact of the existing code implementation and didn't actually serve any other useful purpose. this then resulted in re-examing the design-point and requirements for digital certificates, certification authorities, and PKI ... which was to address an introduction issue where a relying party was facing first time communication with a total stranger and had no access to any other means for obtaining information (aka the letters of credit model from the sailing ship days). In situations where there was an established relationship between the two parties ... it was fairly trivial to demonstrate that the digital certificates were redundant and superfluous. so the original justification for server domain name digital certificates in SSL was 1) key exchange ... which can be done via other mechanism 2) address perceived integrity issues with the domain name infrastructure so that the user has some level of confidence that the server they think they are talking to actually is the server they are talking to. basically, the browser checks the typed-in URL against the domain name in the server's certificate. this originally was specified as happening at the time the user typed in the URL that initially contacted the server and the SSL session existed for the complete period that the user interacted with the server. however, most servers very quickly discovered that SSL operation cut their thruput by 80-90 percent and so you found e-commerce servers moving to straight HTTP w/o SSL for the browsing and shopping experience and providing a "checkout/pay" button that moved into SSL for actual payment. As been repeated described before this creates a large vulnerability in the SSL use for real live environments ... since if a user was initially interacting with a fraudulent site (because SSL wasn't used for the original typed in URL) ... when the user got to clicking on the "checkout/pay" button ... a fraudulent site was more than likely to specify a URL for which they had a valid server domain name SSL certificate. the other issue ... is most of the certification authorities in the world aren't actually the authoritative agency for the information they are certifying. the actual trust root for many digital certificates ... are the authoritative agency that the certification authority has to check with regarding the validaty of the digital certificate application. Now, it happens that the authoritative agency for domain name ownership, is the domain name infrastructure ... the very same domain name infrastructure that has the integrity concerns giving rise to the requirement for ssl domain name certificates. so there has been some proposals for improving the integrity of the domain name infrastructure ... in part from the certification authority industry so that the certification authority process can better trust the information that they are certifying. Part of this proposal is to have domain name owners register their public key with the domain name infrastructure. Future communication between the domain name owner and the domain name infrastructure would be digitally signed and the domain name infrastructure can verify the digital signature using the on-file public key (note no digital certificates required) http://www.garlic.com/~lynn/subpubkey.html#certless The other benefit is to the ssl domian name certificatin authority industry ... they can change an expensive, error-prone, and time-consuming identification process (matching the identity of the certificate applicant with the identity of the domain name owner on file with the domain name infrastructure) into a simpler, less expensive, and more reliable authentication process (by requiring that certificant applicants digitally sign their applications and the certification authority then verify the digital signature by doing a realtime, online retrieval of the onfile public key). Of course, this represents a signficant catch22 for the ssl domain name certification authority industry; 1) if you improve the integrity of the domain name infrastructure it reduces the requirement for having ssl domain name certificates 2) if the certification authority can base their trust infrastructure on realtime retrieval of online public keys for authenticating digital signatures ... it is possible that the rest of the world could also start doing realtime retrieval of online public keys for authenticating digital signatures (eliminting the requirement that a webserver needs to transmit a digital certificate to a relying party in order for them to verify a digital signature). One could even imagine an enhanced, optimized hostname->ipaddress transaction with the domain name infrastructure ... where the ipaddress, any public key, and other optional information all piggybacked in a single response. Then the client could do a real, transaction oriented operation ... they piggyback the encrypted random transaction symmetric key and the encrypted transaction data in a single transmission (to the webserver) ... with the webserver being able to do a single transmission reply. None of the certificate related protocol chatter needs to even occur ... you have a single round-trip with the domain name infrastructure (if the information isn't already cached locally) and it is possible to also have a single tround-trip transmission with the webserver. slightly related post in another thread http://www.garlic.com/~lynn/2005n.html#43 X509 digital certificate for offline solution http://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline solution --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]