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: [Clips] The summer of PKI love
On the token front, we're still unfortunately waiting for the ideal key storage device. USB tokens, smart cards, and cell phones are all candidates, and the pros and cons of these options form a complex matrix. Universities tend to prefer the USB approach because the tokens work with PCs and Macs that can't easily be outfitted with card readers. On that subject I highly recommend a report very recently published by DFN-CERT and SurfNET. http://www.dfn-pca.de/bibliothek/reports/pki-token/ : Abstract The usage of X.509 certificates and related PKI techniques is getting more and more common. It enables users to sign and encrypt messages, to use secure communication channels for internet communication and to authenticate themselves to all kind of network services. The overall level of security for the usage of public key cryptography depends heavily on that of the private key, which is usually installed on the local host of the user. This poses not only a security risk but it does also restrict the increasing user demand for mobility. A solution to these problems can be smart cards and USB-tokens, which store private keys in such a way that they cannot be retrieved from these. Instead data can be send to these devices and is being processed, decrypted or signed, by the device itself and only then the results are provided by these devices for further processing. These devices are very promising for the widespread usage of PKI. In a PC- dominated world the USB-tokens have the advantage, that no additional reader is necessary to use them even on foreign hosts. Both types of devices, smart cards and USB-tokens, still need support by the underlying operating systems and by the used applications. This makes it very difficult to decide which token may be successfully used in any given environment and will meet the demands of the applications and indented usage. This report tries to ease the decision process when selecting a token for a particular environment and platform. For this purpose a number of the available tokens were tested together with the most common applications on the most commonly used operating systems. A reproduceable test framework was established to ensure the comparability and re-usability of these tests. Overall it is safe to say in a homogenous environment with commonly used applications the tested tokens perform well. Nevertheless rolling out tokens on a large scale is still not something to be undertaken on a friday afternoon. [snip] Cheers, Stefan. --- Stefan Kelm Security Consultant Secorvo Security Consulting GmbH Ettlinger Straße 12-14, D-76137 Karlsruhe Tel. +49 721 255171-304, Fax +49 721 255171-100 [EMAIL PROTECTED], http://www.secorvo.de/ --- PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Clips] The summer of PKI love
-- From: Stefan Kelm [EMAIL PROTECTED] The usage of X.509 certificates and related PKI techniques is getting more and more common. It enables users to sign and encrypt messages, to use secure communication channels for internet communication and to authenticate themselves to all kind of network services. The overall level of security for the usage of public key cryptography depends heavily on that of the private key, which is usually installed on the local host of the user. This poses not only a security risk but it does also restrict the increasing user demand for mobility. A solution to these problems can be smart cards and USB-tokens, which store private keys in such a way that they cannot be retrieved from these If the token has no user interface, or minimal user interface, and the mobile user uses the token to log on to a corrupted computer, then the adversary has control of the token, even though the rightful user retains physical control of the token. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG k8jT9lI+qnD2l9zmgoEnD1dREI6nEAq21MKjTBy2 4l82lryIH7nTP4rjhCMmKYcuZkd3xQSd8Mtpt1S8d - 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
The summer of PKI love
http://www.infoworld.com/article/05/08/10/33OPstrategic_1.html The annual PKI Deployment Summit at Dartmouth College is becoming a summer tradition. Universities differ from other large enterprises in ways that make them bellwethers for IT's future. ... snip .. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[Clips] The summer of PKI love
--- begin forwarded text Delivered-To: [EMAIL PROTECTED] Date: Thu, 11 Aug 2005 15:10:52 -0400 To: Philodox Clips List [EMAIL PROTECTED] From: R.A. Hettinga [EMAIL PROTECTED] Subject: [Clips] The summer of PKI love Reply-To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] http://www.infoworld.com/article/05/08/10/33OPstrategic_1.html InfoWorld The summer of PKI love Dartmouth College's PKI Deployment Summit showed public key infrastructure moving forward Strategic Developer, By Jon Udell ? August 10, 2005 The annual PKI Deployment Summit at Dartmouth College is becoming a summer tradition. Universities differ from other large enterprises in ways that make them bellwethers for IT's future. University user populations are transient, platform monocultures cannot be imposed, and collaboration across institutional borders is mission-critical. These are excellent circumstances in which to evolve methods of identity management that will also meet the requirements of corporations as they increasingly outsource, connect with customers through the Web, and engage with partners in federations of Web services. One reason for PKI's slow uptake has been the lack of two kinds of portability. It hasn't been easy to move cryptographic keys from one machine to another, or to use credentials issued by one institution at another. But as we learned at the summit, there's been progress on both fronts. Growing adoption of hardware tokens is making cryptographic identities independent of machines. And emerging trust bridges are enabling those identities to be federated among universities, the federal government, and industry. On the token front, we're still unfortunately waiting for the ideal key storage device. USB tokens, smart cards, and cell phones are all candidates, and the pros and cons of these options form a complex matrix. Universities tend to prefer the USB approach because the tokens work with PCs and Macs that can't easily be outfitted with card readers. No matter what flavor of device, however, the deployment procedure is critical. This year, several summit attendees talked about moving away from a model in which the token caches keys that are also stored elsewhere, to a model in which keys are generated directly on the token and are stored only there. If you lose your token, you have to reregister for a new one and get freshly minted keys. Work-arounds are painful experiences that people won't lightly inflict on themselves a second time. It sounds draconian, and indeed is, but the benefits are twofold. It virtually eliminates password sharing, which, as I mentioned last year, is otherwise rampant. And the required in-person registration is a ceremony that helps users understand what the token means and how to use it. On the trust front, a number of initiatives are under way. A handful of universities and resource providers have been using the Internet2 consortium's Shibboleth to enable users at one institution to access online resources at another. In March, that trust network was formalized as the InCommon Federation. Shibboleth isn't PKI-based, but it can be bridged to PKI systems, and trust bridges were a hot topic this year. Dartmouth's Scott Rea gave a status report on the Higher Education Bridge Certification Authority. Peter Alterman, from the National Institutes of Health, described the Federal Bridge Certification Authority. Cybertrust's Russ Weiser presented Secure Access for Everyone, which focuses on the biopharmaceutical industry. And Jim Jokl, from the University of Virginia, showed how to leverage grid networks as a trust fabric by exploiting the Globus Toolkit's intrinsic PKI. Once these and other bridges can cross-certify, token-borne credentials issued by one will be recognized -- subject to appropriate policy mapping -- by the others. A year ago that seemed far-fetched, but the picture is coming into focus. Jon Udell is lead analyst and blogger in chief at the InfoWorld Test Center. -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' ___ Clips mailing list [EMAIL PROTECTED] http://www.philodox.com/mailman/listinfo/clips --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire
