David Schwartz wrote: > And with respect to the other thread, I agree with you. The level of > security should be the highest that doesn't require sacrificing things that > are more important than security. Sometimes all you need is to keep out your > kid sister, sometimes you have to keep out professional spies financed by a > major government. The solutions appropriate to those two extremes are very > different. Don't let the fact that you can't feasibly implement a perfect > solution keep you from implementing one that is more than good enough.
X.509 was written to support SET (Secure Electronic Transactions), and standardize the things that SET needed. X.509 wasn't appropriate to the Internet, and that's why the "Internet Profile" (PKIX) was issued. Unfortunately, the people who wrote the PKIX were people trying to make the protocol have the things that the financial services/fiduciary communities needed. Many of the things in there just do not apply to the things that general users of the Internet use the Internet for. The cryptographic security folks are so overwhelmingly pedantic to "absolute measures of security" that they forget the concepts of "relative security" and "usability". (Case in point: browsers treat a 'cannot verify certificate' as a complete failure mode, requiring a modal interaction, instead of allowing the page to show up with a pop-up or balloon tip that says "we don't know who this is, the certificate says this, and it's issued by that, and we don't have any guidance on whether to trust that or not". This is particularly annoying when trying to, say, browse an svn server that has a self-signed cert.) Rather than including lists of "approved certificates" and relying on them as though they're Holy Writ, I think the direction that needs to be taken is one where inability to chain to a 'trusted' root is a common occurrence. My case for this is basically that web forums exist on their own recognizance, and users create accounts on them, sharing personal information, without any cryptography whatsoever (and thus, without any assurance of identity whatsoever). Users should not be penalized with modal dialogs and security warnings that jar them out of their browsing mindspace just because they want to make sure that the information they have isn't eavesdropped along the way to the site. Besides. If web forums get to the point where they can set up their own CAs (self-signed certificates), then they can also issue identity credentials for the user accounts they manage -- say (for example) that I have [EMAIL PROTECTED], Google could issue me a certificate for '[EMAIL PROTECTED]' to prove that I actually do have the Google account no matter what medium I'm communicating over. This would allow me to use this identity for IMing on networks other than Jabber. I also have 'aerowolf' on a few other boards. If I want to communicate with people who are also part of those boards' communities in places other than those boards, I should be able to (for example, to prove my identity to an IRC server, or a DCC chat). The upside for those boards? increase communication between members without increasing storage and network costs. The downside? Fear of the CA Policy Document. There are a lot of issues that need to be ironed out in this idea, but I've been working on it for the past couple years. I'm just sick of having this wonderful and interoperable toolset available, and nobody using it because they're all terrified of "additional liability" and "huge amounts of work". Not to mention "lack of client support", "lack of useful mappings to everyday internet usage concepts", and "lack of motivation to change the unencrypted status quo". There was more activity in the months leading up to the potential imposition of the Clipper Chip than there has been since -- because the threat to cryptography is no longer perceived. -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
