On 3/22/07, Gervase Markham <[EMAIL PROTECTED]> wrote: > Kyle Hamilton wrote:
> > > 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. Any individual or organization that can run code on my machine can do anything to my machine that the code allows them to do. How am I protected, for example, just by knowing that a given software was signed by Sony BMG when it inserts a driver into the stack of my Windows XP machine's CD-ROM functionality? "I know who to sue" -- that's been the historical statement of why X.509 is necessary -- but quite honestly there's no real set of protections there. > >> 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 Mozilla Foundation is the authority which determines whether a given root certificate is included in its default certificate list. If you're going to assert that it's "provable", you suddenly create a lot more liability for the Foundation -- because it's not provable. For example, if you upgrade Firefox, does the root certificate store get replaced? If so, then how can local administrators assert their own certificate policy? If not, then how can the user know that the certificate list in the database has been unmodified? Quoting my question and your answer: > 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). How can I, as a user, verify that the certificates that are in my store are the ones that the Mozilla Foundation put there? How can I, as a matter of forensics, tell if it's been adulterated? (Also: your assertion that signing the roots would place a strain on the organization, by placing a highly-trusted key in the hands of an organization which has no experience in key management of that nature, has just been obviated. The MoFo code-signing private key is just as highly trusted, in this particular model, yet it's harder to verify and still leaves the end contents subject to tampering after they have been emplaced.) > > 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? It is certainly a feature -- but it's a "feature" in the same way that debugging capabilities in operating systems are "features". In the right hands, properly used, they do much good. However, they also open up the capability for much harm. My question, which has been inadequately addressed thus far, is this: How can I verify that the certificates that I did not place in the store by affirmative user or administrator action are, in actuality, the certificates that the Mozilla Foundation approved? You can put a technical measure in place to attempt to prevent additions to the root store, or you can make the data that MoFo placed there verifiable back to MoFo. > > > 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. Great, make Big Brother even more intrusive by preventing organizations like CAcert from signing any useful certificate. I prefer gracefully degraded functionality which still allows it to "work", while enforcing warnings on form submission. > >> 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? To find that, just find who blocks all the proposed chrome changes in the security area of bugzilla. I believe you can look for the issue about S/MIME certificate handling presenting a denial of service if they included a bogus root certificate with their certificate chain, and the same name as an existing issuer. This was fixed in 2004, but that issue is the one that comes most clearly to mind. > Kai made some chrome changes recently, I believe. He rewrote some error > messages to be better. "Rewriting error messages to be better" is not the same as "change any part of the workflow". If we /can/ touch the chrome, then why are the important pieces of the certificates still hidden in the full DER parse tree? Why is it still so difficult to get the certificate's full subject? -Kyle H _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
