On Sep 6, 2007, at 11:24 PM, Nelson Bolyard wrote: > No other success stories? > Are there really no other readers of this list using their own > personal > crypto devices for reading/writing signed and/or encrypted email? > > Maybe NSS is way overkill for the needs of mozilla users? > > _______________________________________________ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto
Nobody uses it because nobody understands it. Nobody understands it because nobody understands legalese. Everything associated with cryptography (the way it's practiced today) has to do with legalese -- knowing the legal identity of an entity so that you could perhaps later sue them for some unknown reason. Everyone prefers to use unsigned/unencrypted systems because they are less complex to set up. They are more invisible -- they don't needlessly throw up messages about 'warning!'s that exist outside of the sender's or receiver's control (have you ever tried to use signed messages via Outlook Express over Hotmail? They append a Hotmail footer to every message body, which invalidates the signature). They are less frightening -- "what do you mean, my full legal name and address and everything is going to go out for anybody to read?!" [the envelope information isn't kept secret in PEM, and certificates are sent unencrypted via TLS unless an anonymous cipher's used first and then a full protocol renegotiation with certificate presentment occur after the anonymous cipher is established]. They have fewer moving parts that all have to be set up in just the right way. Frankly, cryptography as implemented everywhere is a failure. Nobody understands PGP, nobody uses it. Nobody understands NSS (or the underlying concepts of X.509), nobody uses it. We only buy the certificates for our servers because of the "Netscape Tax" -- the requirement that Netscape built into its browsers that every server must have a valid X.509 certificate signed by a pre-approved entity that Netscape contracted with. The user didn't even get the chance to choose what entities to trust until later -- and that process is still so arduous that no user would really want to try to learn how to. Enforcing this concept that X.509 (and the X.500 naming hierarchy, and everything associated) is the One True Way is certainly the only way to keep the US military, or governments in Europe, in tune with it -- but really, the requirements that the usage model impose create a hardship for everyone else who's trying to use it for non-Legal purposes. Nobody should have to be so rigidly regimented when they try to use it unless they're trying to adhere to Legal requirements. The amount of information in a certificate is staggering. It takes training to be able to read an actual certificate ["what's this "S=Kyle Hamilton,[EMAIL PROTECTED],CI=Las Vegas,ST=Nevada,C=US" mean? Do I speak for the City of Las Vegas simply because I'm located here in the X.500 Directory structure?]. It takes tools that most people have never heard of or used to be able to get anything useful out of a certificate (openssl asn1parse being one of them). The certified information is so hidden by the chrome of every application that uses it that it's only the most truly paranoid people who look at it anyway. ...and even then, the information they need to see isn't put in front of their face when they double-click the lock icon, they instead get a completely worthless explanation of just what 'security' (in the context of an un-wiretappable TCP connection) means. It takes at least one more click to see the information that the X.509 certificate is supposed to certify. And now, we have laws that protect childrens' information. This means that if a kid goes to a site that accepts certificate-based authentication, then they've suddenly made the operator of that site liable -- they don't even get the chance to say "we don't want kids' information" unless they design their webservice really well. So now, client-side certificate-based authentication systems are now too risky to put in place. (On the flip side, we now have Sarbanes-Oxley and other requirements, so we have business needs that non-business users need to not have to deal with.) It's very, very disheartening to see everyone beat their heads against the same structural walls that they've built around themselves when the reality is, the use of cryptography just cannot become a sustainable, thriving, useful, ubiquitous, invisible technology until these design flaws are worked out. I believe that NSS -- overkill as it may be for most users at this time -- does provide very useful functionality for anyone who might be interested in looking at alternative information which might be held in a certificate. Cryptography, as a whole and holistic concept (everything that goes into it), needs a thorough, systemic revamping in every system that has been designed to use it. NSS (and TLS in general) has shown a very important thing: it's possible to get TLS- encrypted TCP connections that Just Work, regardless of what ciphers or versions are supported by either side, or even if neither side authenticates itself with a certificate. The rest is based on cryptographic verification of asserted information, and a securable data store. That's really what it boils down to. Scary, isn't it? But, it paves the way for different information to be put into it, a reimagining of what authentication can mean, of what identification can be. (I should point out that I actually like having the legal information of an entity that I do business with available, but I've also been finding that some things I'll take the risk of not having that information specifically available. The credit card industry has all but completely and voluntarily dropped the liability for fraudulent transactions against credit cards to zero, at least in the US that I've seen... and it's very easy to file a complaint against an e- tailer that doesn't send the right goods or sends no goods at all. So even the threat of monetary loss isn't there to make people recognize the importance of knowing who they're dealing with.) TLS, btw, is the only cryptographic protocol that the IETF has gotten even remotely right. PEM? A joke. IPSEC? Even worse. None of the current institutional applications imagined by cryptographic protocol designers is in wide use. I don't think that the designers of these protocols have intentionally tried to make the situation bad, and I think they're all intelligent people. What I do think, though, is that his suggests a bit of a flaw in the common mode of thinking among them. We don't need a technology, in the non- Legal environment, that provides Legal information and only Legal information. We need a technology that can flexibly contain broad types of data, and we need systems that can flexibly deal with the data that is presented. Perhaps more importantly, we need flexibility in our thinking of what the important ideas of identity are, per-context. I've touched on three separate pieces, so far: usability, interoperability, and the threat model employed. I'll touch on usability a bit more, then compare X.509 with another, newer, more- well-implemented technology, and then I'll get off this soapbox. I was just browsing around the Apple Downloads site, under the Networking and Security division. I saw an entry for something called "SimpleAuthority", a software to ease the pain of running a Certificate Authority. Intrigued, I downloaded it, and I ran it. And... well, it's every bit as simple to operate as its name promises. (Unfortunately, it's not open source, and it caps at 6 different people for whom to issue certificates.) We need easier-to-use software to manipulate the secure repositories for our certificates. We need a reason for people to want to manipulate those repositories in order to see just what it means that the user interface is "bad" -- but they won't want to until an easier- to-use system exists. Why does it have to be so difficult to create a CA? Why does it have to be so difficult for the CA to get you to generate a CSR? Why does it have to be so difficult for you to get the certificate into your software once it's issued? And why is there such a concept of a 'signed certificate' being a magical and mystical string of bits that only an approved entity can issue? [I can see X.509 -- when used for legal identification/ authentication purposes -- having a need for such approval. I can't see such approvals necessary for any situation that doesn't have legal identification/authentication requirements... such as logging into a website, or signing messages as being from a member of the website. In that case, the website stores its database of authorized users, and the website should issue certificates to its users as the authority for the identity domain.] At the moment, OpenID is more useful and usable than X.509. OpenID was developed in the last 5 years. X.509 has had multiple iterations for over twenty years. OpenID also has implementations for what it does, implementations that are actually useful. X.509... well, doesn't, really. Why can't we change that? Why can't we point to any specific application of X.509 and say "this is what it lets us do"? I would submit that OpenID actually has a use, that people can use as it stands. X.509, the PKI needs to be put in place and then all the applications out there need to be built to support that as an authentication mechanism, and then each user needs to individually be enrolled. Thus, OpenID has the 'low barrier to entry' concept in place. However, there are three things that X.509 allows, that OpenID does not, that could be used as leverage for integration. First, it allows offline use. (OpenID requires that you are online to verify the authentication.) Second, it allows for a knowledge- based authentication server versus a location-based authentication server. (This can be used for anything that needs to be built such that attacks against a location-based authentication service are completely mitigated. It also allows for situations where online/ location-based authentication would have too much overhead.) Third, it allows for cryptographic knowledge protocols to be used. (bit- commitment and such.) These are my views on cryptography as a practiced art as it stands today. I have been explicitly focusing on the non-Legal environments (Legal with a capital L, to suggest the industry/environment rather than as a description of a type of act or environment -- i.e., situations where you need to know who signed a contract versus situations where you don't.) I am very sorry if I offend anyone with these views. -Kyle H _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
