Mozilla

In the course of our discussing the proposed Mozilla CA certificate policy, Ian Grigg happened to ask about the existing Mozilla policy on handling security bugs and how we tried to forge a compromise between people advocating full disclosure of security bugs and people who were opposed to that. (Ian was interested in this because he and Adam Shostack have been blogging on the “economics of disclosure.”) I happened to look back at the Google archives of the discussions we had, and found some material that I thought was worth revising, reprinting, and commenting upon, especially for people who are not aware of how the current Mozilla policy came to be. ...

I’ve created a new draft 9 of the proposed Mozilla CA certificate policy. The main substantive changes are as follows: I extended the policy’s requirements to cover all CAs, not just new CAs. This puts existing CAs on notice that in the future we can (and I hope will) go back through the list of CA certificates already included in Mozilla-related products and decide whether or not particular CA certificates should continue to be included. ...

I’ve created a new draft 8 of the proposed Mozilla CA certificate policy. The main substantive changes are as follows: I changed references to “users” to clarify that we’re referring to users of the products distributed by the Mozilla Foundation through mozilla.org. I added a requirement for CA disclosure of business practices in the form of a Certification Practice Statement. Besides being a good idea in general, it’s typically the CPS that is referenced in auditor/evaluator reports, so it’s needed to provide a more complete picture of the CA’s conformance to whatever criteria are used to evaluate its operations. (For examples of Certification Practice Statements see my draft Mozilla CA certificate list.) ...

I’ve published a new draft of the proposed Mozilla CA certificate policy. For information on changes from the previous draft please see my posting in the netscape.public.mozilla.crypto newsgroup (aka the mozilla-crypto mailing list). (Note that I have not yet completed writing the accompanying FAQ, but will try to do so in the coming weeks.) This new draft is intended to replace the simple “WebTrust or equivalent” policy that I’ve been using recently when deciding whether or not to approve CAs for inclusion in Mozilla-related software. (This interim policy was based on Microsoft’s policy.) ...

A while ago someone wrote to mozilla.org staff asking “What is the ECCN for Mozilla?” For that small fraction of the world’s population who knows what an ECCN is (an “Export Control Classification Number” for U.S. encryption export control regulations) and cares about what Mozilla’s ECCN happens to be, here’s the answer I gave. Note that this is not an “official” answer, but it’s the closest thing to it you’re likely to get. ...

I have published a new draft 5 of the proposed Mozilla CA certificate policy. For detailed line-by-line changes from the previous draft please see my posting in the netscape.public.mozilla.crypto newsgroup (aka the mozilla-crypto mailing list). (Note that I have not yet updated the accompanying FAQ, but will try to do so in the next few days. Unfortunately for various reasons I will have less free time during the holiday season than I would normally, so I can’t commit to getting this done right away.) ...

I’ve been working on the Mozilla CA certificate policy for some time now. I’ve created a “metapolicy” to help guide how the final policy should look. Note that the metapolicy doesn’t address any of the truly hard issues, like how to evaluate Certificate Authorities that haven’t undergone WebTrust audits or other independent audits. That will have to wait for future work (and time for me to do it). In the meantime I’ve been following a simple interim policy, one that is basically equivalent to Microsoft’s policy: I’m approving CAs that have successfully passed a WebTrust for CAs audit, or an audit that (in my judgement) is “WebTrust equivalent.”