On Sun, Nov 9, 2008 at 7:26 AM, Eddy Nigg <[EMAIL PROTECTED]> wrote: > On 11/09/2008 04:25 PM, Ian G: >> >> Well, all the arguments have been heard on this already, and positions >> are fairly entrenched. It seems futile to have the debate over and over, >> and I for one would like to point out that it is uncomfortable to treat >> it like a political campaign. > > Well, Kyle stated that he doesn't care who I am nor which interests I > represent. This was a short statement about what I did and which interests I > represent (including obviously my personal preference) :-)
Since there's a fairly argumentative tone going on, I think I should explain what my viewpoint is: 0) First and foremost, I'm a citizen and resident of the United States of America, educated in the public school system in the 1980s to early 1990s. This means that I was brought up with a particular set of beliefs (most notably that only governmental authority is proscriptive, and there is no generally-applicable prescriptive authority). This colors every value judgement that I make, most importantly the following... 1) I believe that users who own their own machines are sovereign. The USER, not the CA, is the root of all trust on that user's machine. (Families are different, but only in that the actual owner of the machine -- usually a parent -- is the root of all trust for the kids who use it. There are many rights which corporations have that family owners don't, including the right to capture and log keystroke, video output, audio output, and network activity on the machine.) 2) I believe that CAs which have been audited against their CPs and CPSes have a severe disincentive against making new types of certificates available. 3) I believe that CAs which have been audited against their CPs and CPSes have a severe disincentive against binding different types of identities (other than legal identity) to public keys. The reason for this is that CAs must adhere to their CPs, and thus far none of them have brought any expression of non-legal identities (this is different from 'illegal identities', which include identities that people take on for the purpose of defrauding another or any identity used for an illegal purpose) into their certificate policies. 4) I believe that CAs which have been audited against their CPs and CPSes have a severe disincentive against placing user-requested extensions in their certificates, because these extensions can mean anything and be interpreted as anything. 5) I believe the disincentive against placing user-requested extensions in certificates reduces the incentive for general-purpose PKIX clients to properly handle arbitrary extensions -- the information doesn't exist, so there's no implementation thereof. If there's no implementation thereof, there's no pressure to provide the implementation. 6) I believe that the USA has a chartered requirement to not infringe on anyone's right of free association. (Among other things, a person can associate with gays -- and one of the more deeply-held beliefs in the gay community is that if you know that someone's gay, you do not under any circumstances make that group membership known -- it is the individual's decision when (or if) to "come out of the closet", i.e. make their own group membership known. I have other examples to suggest that this is an appropriate view to take, but I cannot express them without betraying my own associations in ways that I wish not to.) 7) Because of #1, I believe that users have the right to use their computers as tools they can work in any manner, for communications they wish to share in any manner, and with pseudonyms as they may require or desire -- not simply with the de facto legal identity information embedded in ways that CAs currently require. Also because of #1, I believe that assigning "ultimate trust" to any CA that is not run according to the need of the user is a violation of the user's sovereignity. 8) in light of #2, 3, 4, and 5, I conclude that trying to get any audited CA to embed a non-legal identity or group-membership extension is pointless. 9) in light of the interactions between #3 and 6, and the conclusion in #8, I conclude that using the current CAs for anything outside of the top-down, hierarchal, legal-identity declaration that they currently are is pointless. 10) I believe that there are many, many applications that would benefit from the application of cryptography. However, the dominant paradigm of cryptographically binding an identity to a key (but only as long as the identity that's bound is the legal identity) makes it difficult for advocates of cryptography to gain any traction in those environments. In addition, regarding your desire to do away with self-signed certificates as website identification... unfortunately, I can't see a way within a strict reading of X.509 to do that. I do believe it would be good practice, but it just seems to be... well, dogmatically prohibited. As far as I've been able to figure out, all trust flows from the trust anchor... so the trust anchor itself can be used for any purpose for which it's trusted. "I trust this anchor to authenticate websites. If I see the trust anchor itself in a certificate for a website which authenticates according to Subject and SAN processing, I will trust it even though the key itself is being used in a way that it should not be." (A few years ago we had a discussion on here which led to the statement that the 'trust anchor' is not the CA certificate itself, but rather the CA's public key.) Also, the case that Nelson brought up would have been made less intrusive into the user's mindspace by simply asking the user to accept a CA which (even with the same key in the server certificates) would have only brought a single security exception dialog up. As well, with the new multi-process database capability, it will now be possible for a rogue extension to add CAs to the profile's certificate database without any intervention from the user and without any corruption of the database, which would make for a discoverable but not obvious security boondoggle. > Perhaps I should have added, that I'm coming from the same grass-root camp > as Kyle and others. WE have/had some very similar goals... however I > actually did something in order to establish an alternative. I was the > thriving "force" behind the establishing of a legitimate authority where the > commercial aspects aren't the primary goal and where certification isn't > bound to the financial capabilities of the subscriber. By trying to appear 'legitimate' the authority which you created falls into the same problems which plague every other authority. As well, since the 'authority' that you run does not issue the credentials which can be used to authenticate a legal identity, your 'authority' is not 'authoritative'. That's one of the most important things that CAs need to recognize -- they're not authoritative for anything which they are not the sole arbiter of. (A user group is authoritative on its membership, but a general-purpose certificate issuer is only authoritative on 'the entities which have chosen to request issuance of a certificate from it' -- the general-purpose certificate issuer is not authoritative for 'the identities of entities'. In this light, even the DMV/MVD isn't authoritative, and it's only because the US Department of State takes several weeks to verify presented documents with the issuing authorities that it really can be called authoritative for US citizenship and passport issuance.) > For some reason, advocates like Kyle are opponents to us today and needless > to mention that the hard-core CAcert crowd isn't happy with what we do and > achieved either - first we were ignored, then publicly laughed at, then > publicly decried. Go figure... I have no issue with what you're doing, and I think that it's a very good thing. I believe that the CAcert project is interesting, at least insofar as it's getting more people to be aware of the massive issues of legal identity (individual and corporate) and legal name as they are interpreted around the world. What I do have issue with, though, is that you seem to think that the service you created is a panacea, that the concept of monetary exchange is the only thing which prevents people from using the services of the general-purpose CAs. It's not. (Among other things, you issue end-user certificates, which cannot themselves issue other certificates. This means that a user cannot use the certificate you issue to issue certificates to his router, his PC, to his friends, to any services that he chooses to run -- all he can issue are proxy certificates, which cannot be used for identity; they can only be used for delegation of the permission that an end-user certificate has. Since end-user certificates cannot be used to identify servers, the end-user still has an artificial barrier to entry if he wants to, say, protect his home network with ipsec.) > Today I'm afraid that for those I don't have much sympathy left either and > continue to serve those who appreciate it. I have issues with the entire X.509 paradigm, but the biggest problem is this: X.509 was designed around the concept of a central, worldwide Directory. This would have made Subjects (and SANs) searchable, globally... and the fact that there is no centrally-searchable database is what allows for certificates to be mis-issued by audited and trusted CAs, under the strict readings of their CPs. >> It seems that Eddy and Nelson are in the anti-self-signed-certs camp, >> and I would join Kyle in the pro-self-signed-certs camp. > > I think that's way too simple... I agree, this characterization is far too simple. I just want to maintain the ability for users to reason their ways through the process of adding new roots to their stores. I would like to simplify this process as much as possible. I would like to ensure that it is a "reasoning" process, though, rather than just a "the damned browser's getting in my way so I'll accept this" process. I think I would be amenable to the following: 1) A certificate should not be self-signed if it is being used to identify a server, as a means of encouraging best-practice CA key management. 2) If a certificate issued by a CA and a known CA have the same key, the certificate should be flagged for review (again, encourage best-practice CA key management). 3) The process of adding a CA should not be directly accessible from the security exception UI. Individual sites should be able to have their certificates added on a case-by-case basis, because a site may be legitimate in the user's estimation even if they don't want to trust the authority identifying it. (This is outside NSS's scope.) 4) There should be an extension defined in CA and end-entity certificates for a CA to embed information on how to add the CA to the trusted store. (There's already two extensions defined for CAs to link to their certification practice statements, but none for any tutorials or information on how to add a CA to the root store.) This link could be shown in the security exception UI. (This is outside NSS's scope.) 5) The security exception dialog (even if it's not an actual dialog box, it's still an interaction between the user and software) should also have a prominent link to the criteria for inclusion in the default NSS database, and those criteria should have their rationale explained -- so that the user has the ability to understand what exactly is at stake. As well, there should be a statement "Mozilla, Firefox, and NSS take no responsibility for any consequences which may happen if you add a CA that they have not included." (Again, outside of NSS's scope.) > You don't have to search a lot....just visit Paypal and look at your > browser. That's the way the wind is blowing. And if regular certificates are > further circumvented and devalued, this is what you'll be left with in the > end. Think about it! Er, honestly? "regular certificates" have already been devalued by the entry of over 100 competitors to Verisign. The chrome for the browser, everyone keeps telling me, is outside the scope of this group -- so why bring it up? But, since you did, I'll return an anecdote... The fact is, "regular certificates" didn't go far enough. The idea of domain-validated certificates was created by an audited and accepted CA, and that idea appears to me to be what led to the creation of the EV certificate profile by the CAB forum anyway. I removed my trust in Firefox for every CA that I could find a CPS for which suggested that they could issue domain-validated certificates, and I found that the browser's chrome made it impossible for me to get anything done after I did that. I brought up the additional cost for EV certificates before; you thought it wasn't appropriate for me to bring up because "only major e-commerce sites and banks" would need them. And now, you seem to suggest that eventually, it likely will end up that everyone who touches credit card numbers or other fiduciary data will need an EV cert anyway? I hate to say it, but look within your own industry for the cause for that. (And then realize -- once again -- that MasterCard and Visa, at the least, offer a $0 liability to anyone who has a fraudulent transaction posted to their account. The credit card issuers have already taken action to protect their clients... so what exactly is it that any certificate is supposed to protect against, at e-commerce sites? AFAICT, it's only really banks and other fiduciaries that need the EV protection. The idea that everyone needs an EV certificate is a natural herd reaction to the whispers of uncertainty and doubt that the CA industry representatives collectively whisper or have whispered into the ears of those who control the writing of the software.) -Kyle H _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
