Re: The summer of PKI love
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
Re: The summer of PKI love
Stephan Neuhaus [EMAIL PROTECTED] writes: So, the optimism of the article's author aside, where *do* we stand on PKI deployment? The same place we were standing on OSI deployment 15 years ago. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The summer of PKI love
-- From: Stephan Neuhaus [EMAIL PROTECTED] So, the optimism of the article's author aside, where *do* we stand on PKI deployment? 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. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 5l+2/VgKKsZ7L2MtEJUMxtB3jqOuld2RYZgm3QcV 4HS67bQDIU6jSwHy8CH7u3qvqnY5XGqLUbRMG5mgy - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The summer of PKI love
James A. Donald wrote: -- From: Stephan Neuhaus [EMAIL PROTECTED] So, the optimism of the article's author aside, where *do* we stand on PKI deployment? 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. I would rank it closer to 0% myself. Don't get me wrong, we have plenty of PK deployment with SSL servers, just no I. Anyone doing revocation checking? How do you even do it? CRL? Delta CRL? OSCP? Do any browsers really support these things? For those that do does any user actually know how to do it? PKI is a massive undertaking that many seem to confuse with just public key cryptography. Public key crypto is just one component of PKI, and frankly I know VERY few groups that are actually doing PKI and doing it right. What we have are a couple dozen certificate authorities that were deemed trustworthy by Microsoft that do not pop up warnings, and the rest that do pop up warnings that most people blissfully ignore. HTTPS is really good for encryption, absolutely sucks in practice for trust. -- Mark Allen Earnest Lead Systems Programmer Emerging Technologies The Pennsylvania State University KB3LYB smime.p7s Description: S/MIME Cryptographic Signature
