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 changed the phrase “independent and qualified third party” to “competent independent party,” because it was less wordy and better captured my intent. (I stole this phrase from the ETSI criteria mentioned below,) I added ETSI TS 101 456 and ETSI TS 102 042 as acceptable criteria, for a number of reasons: The criteria in these two standards are comparable to the criteria in the ANSI X9.79 and WebTrust documents already considered as acceptable. These two standards were created for use in the EU, and ETSI TS 101 456 in particular is (or likely will be) referenced in national digital signature laws of EU member states. This is important since the majority of the new CAs that have been applying for inclusion are located in the EU, and many of them have been certified for compliance with their respective nations’ digital signature laws. Unlike ANSI X9.79 (which costs USD 50) these two standards can be downloaded at no charge. (However ETSI does require that you register and provide a name and email address.) Unlike the WebTrust criteria these two standards do not presume the use of authorized accounting firms as evaluators. I changed the definition of “competent party” to delete “reputation for” in reference to “honesty and objectivity,” since the previous language was redundant. I changed the definition of “independent party” to include a requirement for disclosure of financial compensation in certain cases. This is intended to cover the case of a volunteer evaluator who is reimbursed by a CA for expenses incurred during an evaluation; the previous language prohibited any such financial compensation, no matter how small. I believe that such compensation is acceptable if it is disclosed, so that we can then determine whether or not the nature and amount of the compensation is such that it would cause us to question the objectivity of the evaluator. ...

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 removed the explicit reference to knowledge of X509v3 in the qualifications for an independent and qualified third party. I consider it implicit in the reference to “related standards” and I’m not sure how useful it is to single out X509v3 in this context. I explicitly allowed for the possibility of the Mozilla Foundation doing its own CA evaluations, as requested by Zach Lipton and others. Note that I worded this clause the way I did because in practice such evaluations—if ever done—would almost certainly be done not by actual Mozilla Foundation employees but rather by someone else designated to act on their behalf. I added a note that we will reject CA requests if we don’t get the needed information in a timely manner. In part this is to motivate me to actually resolve requests with a “yes” or “no” answer, as opposed to letting them sit in Bugzilla without action. (I’ll definitely plead guilty to this, and I apologize to the CAs for which it’s happened. I’m going to try this month to go through all the CA-related bug reports and resolve them one way or another.) ...

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.”