Kyle Hamilton wrote: > I thought we'd had this type of conversation before... or maybe it was > on the TLS discussion list, and I'm not remembering. Regardless...
I don't remember participating in one; maybe I wasn't around, or maybe it was elsewhere. Regardless, you need to dust off your trusty cluebat. > A "trust anchor" is a public key. (It's not a certificate that contains > the public key, or anything which can be validated with the public key > -- it's the public key itself. It just so happens that an X.509 > certificate is a convenient package for it.) > > A "CA" is a string of characters. It's not a public key or a trust > anchor. (This is the concept that made possible the "S/MIME including > bogus CA certificate disables certificate validation" attack of a few > years ago.) > > All of the workarounds that have been emplaced are limited, necessarily, > by these two concepts. Now, you're advocating placing an external limit > on the trust allowed to be delegated from a trust anchor. (which is > also what EV requires.) However, this is an explicit violation of the > concept of a trust anchor: a trust anchor is the anchor for absolute trust. We already place external limits on trust anchors in this way. For example, certificates in the root store can be allowed to sign websites (or not), emails (or not) and code (or not). Why are you happy with a distinction being made between "websites" and "email", but not with one being made between "this set of websites" and "that set of websites"? In fact, one could argue that the Mozilla Foundation is already the ultimate trust anchor, as we choose the certificates to place in the root store. Most users of products which use the store (e.g. Firefox) are ultimately trusting us to make good decisions about what CA root certs to include. > Within the X.500 model, the better way to do this would be to generate a > CA for Mozilla, convert the self-signed trust anchors into CSRs, have > the Mozilla CA re-sign them with the appropriate restrictions and > validations, and embed the Mozilla root into the library as the absolute > trust anchor. We could do this. However, it would place a highly important private key into the hands of an organisation with little experience in key management at the level required (that is, the Mozilla Project). I'm not sure the security of the system would improve as a result. I guess we could outsource this function. But that has its own issues, many of which I'm sure you can imagine. > (This would also provide an "audit trail" for the > operations performed... i.e., "who said that this CA can't sign a bank's > certificate?" Is there any audit trail today if you go to a site with a CAcert certificate, get an error dialog and ask "who said that this CA can't sign this site's certificate"? > I am ABSOLUTELY against any concept of a "silent and unaccountable" > restriction being placed, on anything. With unaccountability and > silence comes a "what the hell is it set that way for? I'll just fix > it..." mentality without the benefit of being able to see the reasoning > behind it. At least if there's a true anchor that signs things, an > explanatory URL could be placed in its X.509 package and they could see > an explanation of the reasoning. I agree that we need a "lack of silence" and we need accountability for our actions in this regard, but they do not have to be embedded in the certificate chain. I fancy that people who are technically capable of, when faced with a certificate problem, analysing the chain, finding the embedded URL which explains the policy, visiting and it and reading it, are also capable of (in the alternative technical scenario) realising that the organisation which shipped the product must have put a restriction on, and heading over to their website to find out why (if it's not obvious). Particularly if the user agent makes it clear why the error has occurred. Gerv _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
