Back in April 2005 I submitted a draft policy document to the Mozilla Foundation regarding how we determine which Certification Authorities (CAs) have root certificates included in Mozilla-based products distributed by the Foundation. Since that time a lot has happened; in particular the Mozilla Foundation reorganized to move its product development and distribution activities into the new Mozilla Corporation, and I took on a part-time position with the “new” Mozilla Foundation as Director of Policy.
Now that I’m a Director of Policy I thought I should go ahead and actually do something policy-related, so I’m now officially announcing the new Mozilla CA Certificate Policy; I’ll be formally using this henceforth when dealing with CAs who’d like to get their certificates into Firefox, Thunderbird, etc. (I’ve already been doing this informally.)
For more information on the background to the policy please see my prior post. The only changes I’ve made since the policy referenced in that post were to reflect the formation of the Mozilla Corporation as a separate organization. Note also that I intend to publish the policy to the official Mozilla Foundation web site, but haven’t yet done so; I may postpone this until we complete the reorganization of the Mozilla web site.
Thanks go to all the people on the n.p.m.crypto newsgroup and elsewhere who helped in the creation of this policy by providing their comments and criticisms. I doubt that any of the people who provided feedback would approve of all the provisions in this policy, but as I mentioned previously I believe that this policy reflects at least a rough consensus on how we should handle CA certificates (to the extent that consensus exists at all). To the extent that the policy makes sense at all it is due to the efforts of those who constructively criticised it, to the extent that it is incomplete it reflects a lack of consensus, and to the extent that it is flawed it is due to my own failings.
Creating and approving a policy is one thing, actually implementing it is another. For various reasons I haven’t been fully responsive to some of the CAs who’ve been sending me requests for inclusion. The new policy, being more comprehensive than the old one (which basically amounted to “must be WebTrust audited, or the equivalent”), puts more burden on us in evaluating CAs and pursuing all the information we need from them. That will potentially cause additional delays unless I devote increased efforts to handling CA requests; I will endeavor to do so.
Finally, in many ways this policy is just a starting point, and it may be revised and extended in the future. In particular, the policy does not attempt to make distinctions about CAs with regard to the rigor and accuracy of their practices in vetting applicants for certificates. I deliberately omitted this from the policy because, frankly, the existing situation with regard to CA verification of subscribers is very messy: Different CAs do verification in different ways depending on the CA and the class of certificate offered, and independent guidelines (like the criteria associated with the WebTrust program for CAs) do not necessarily impose strong requirements for subscriber validation.
This situation may change in the future. In particular, there is the possibility that CAs may come to believe that it’s in their interest to cooperate on creating common guidelines for CA practices, including agreed-upon recommendations for subscriber validation when issuing so-called “high assurance” certificates. If and when this happens, we may want to change the policy to differentiate between CAs based on their practices, assuming of course that at the same time we also implement the necessary underlying changes in NSS, PSM, etc., to be able to make CA distinctions, as well as changes in Firefox, Thunderbird, etc., to reflect those distinctions in the user interface. But that’s a subject for possible future blog posts…