Kyle Hamilton wrote: > See, identity is identity. I don't agree.
"This site's identity is www.example.com" is a different sort of identity to "This site is owned and operated by Foo Corp. of Bermuda", which is again different to "This site is owned and operated by Gervase Markham, of Enfield, London, UK, passport number XXXXXXXX". But all have their place. > The only function that limiting the types of things that a root can > sign certificates for is to raise the bar and force people who want to > do certain things (like sign code) to get identity certificates from > more expensive sources. Or, alternatively, sources which make correspondingly more effort to ascertain that you are who you say you are. This has the side effect of making the work take more time, and therefore cost more. > To be perfectly honest, in my view X.509 is nearly completely broken > as a protocol, and even more broken as a paradigm. You are entitled to hold that view. However, we're not planning to ditch the current way of securing user <-> site communications any time soon, and I suspect we aren't about to reinvent the certificate wheel either. >> 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. > > No, a 'trust anchor' is a technical location where all trust can be > proven to devolve from (the private key, with the one-to-one > correspondence to the public key). <sigh> You know what I meant, surely? "The Mozilla Foundation is ultimately the location where all trust can be proven to devolve from", with the proof being that you downloaded the software from us and then ran it on your machine and used it to access websites/send email. > The choice of certificates is made by an authority. Without an > anchor, though, it's possible to willy-nilly add certificates to the > database and mark them as trusted. Currently, that's regarded as a feature, although ordinary users are discouraged from using it. What good would it serve to try and put technical measures in place to prevent additions to the root store? > That's straightforward when the anchor isn't in the store. > > What happens when the anchor is already there? The error dialog says "Sorry, the CA who signed this certificate is not permitted to sign a certificate for this website." or similar, better wording. > Challenge: go to http://www.mozilla.org/ and find the root inclusion > policy following links (and only following links) from that URL. > Report how many links you had to go through, and how many unhelpful or > otherwise useless links you also followed. Site Map | Security Center | Mozilla CA certificate policy. No backtracking required. That's not to say that it couldn't be more obvious. But we also have to face the fact that 99.99% of people don't give a stuff about our root inclusion policy. > For bonus points, find a > root inclusion policy on a TLS/SSL-encrypted page served with a > "Mozilla Foundation" certificate which additionally states all of the > approved root certificates and their thumbprints. The approved roots are the ones in the store that you get when you download e.g. Firefox (which is signed by a MoFo certificate). >> Particularly if the user agent makes it clear why the error has occurred. > > Much of this set of problems could be worked around if we could touch > the chrome, but we've had many arguments on this list about the fact > that we can't. Has this policy been changed? People keep stating that we can't, but I've not seen any evidence of this, despite asking for it more than once. Who is the phantom evildoer who blocks all chrome changes on principle? Kai made some chrome changes recently, I believe. He rewrote some error messages to be better. Gerv _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
