Kyle Hamilton wrote: > 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?
Yes, potentially. > If so, then how can local administrators assert their > own certificate policy? As I understand it, when local admins or end users add their own certs, it goes into a different location, with the store being the union of both. > 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? We assert, by signing the download binaries, that the certificates you get are the ones we wanted to put there. Or are you asking how we ensure that the ones we put there are the ones we wanted to put there? > (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 risk is less great, because someone who obtained the signing key would also need to break into our download infrastructure in order to place the trojaned binary. And if they had that power, they wouldn't bother with subverting the root store, they'd just insert the trojan code directly. But yes, you are right, the code signing key is valuable. > 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? By comparing the contents of your store to the appropriate version of the file "certdata.txt" in the Mozilla CVS tree. In the future, there may be a list on a web page. Anyone willing to take on that work would be welcomed with open arms. > To find that, just find who blocks all the proposed chrome changes in > the security area of bugzilla. Oh, for goodness sake. The way for the name in your head to get into my head with full fidelity transmission is for you to actually type it into your reply. (Then perhaps the person you are talking about can defend their actions.) The last time I looked into this, in one sense there were no candidates at all (in that, I couldn't find an explicit "no, you can't, there's a chrome freeze" statement) and in one sense there were lots of candidates, in that various people had expressed opinions of various strengths about the UI. I have no intention of trawling through Bugzilla again to reach the same conclusion. If you want something done about this, name names and give examples. If you really feel you can't criticise someone in public, then send me private mail (still with the examples). Otherwise, I will continue to assert there is no such freeze and you are being paranoid. > 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? Where's the bug with the attached patch and the comments saying "No, you can't put this in because I'm unilaterally instituting a chrome freeze"? Gerv _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
