Mozilla CA certificate policy approved

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

Comments

iang wrote at 2005-11-18 15:11:

Top notch! It was a long hard haul.

Asking CAs to cooperate on subscriber validation is probably the wrong way to go. It is not clear that there is any way to do this; and at a minimum such cooperation will make the entrenched standards more high cost / high barrier with little perceivable benefit. Think for example about 3rd world countries and whether the standards and costs applicable there match the standards and costs in 1st world countries.

It is fairly clear that the "all CAs are equal" assumption is dead wrong.

CAs like CAcert are showing that they can do the whole validation process in different ways and still achieve good results. But they can only do this by re-thinking the basic formulas that the CA structure was built on and by cutting away some of the false assumptions built on the notion of "trust." The sooner browsers can re-introduce the CA back onto the chrome and let the CAs reach to the customer, the better.

Submit a comment

Please enter comments as plain text only; no HTML tags are allowed. All comments and trackbacks are moderated, and will not be displayed until approved by the moderator.

Comments are closed for this story.

Trackbacks are closed for this story.