I have just submitted a Mozilla CA certificate policy 1.0 release candidate to the Mozilla Foundation and mozilla.org staff for consideration as an official 1.0 policy. This version of the policy is basically the draft 12 version with two changes:

  • I explicitly marked the policy as a release candidate.
  • I made a minor change to the last sentence in clause 7 to clarify the meaning of the sentence.

Here is the message I sent to mozilla.org staff recommending adoption of the policy. Note that I tried to distinguish between points on which there has been reasonable consensus (at least among the people who’ve commented on the policy throughout this process) and points on which no real consensus exists (at least in my opinion); I also tried to fairly characterize the nature of any remaining disagreements and indicate the implications for future policy.

As you may recall, some time ago I proposed to create a new formal policy to govern how we accept new root CA certificates for inclusion in Firefox, Thunderbird, and related products. I am glad to report that I now have a version of the policy that I can recommend to you for consideration as an official Mozilla Foundation policy:

Below I provide some background to the policy, a description of its salient features, and a discussion of open issues around the policy that you should be aware of, and that might motivate our revising the policy in the future.

Background: A default set of root CA certificates is bundled as part of the NSS crypto library maintained in the Mozilla source tree and released through mozilla.org. Any product that picks up the standard mozilla.org version of NSS will use these root CA certificates; this includes Firefox, Thunderbird, Seamonkey, Camino, etc. (There are some minor issues like Firefox and Thunderbird 1.0.x maintaining product-specific versions of NSS on separate branches, but we can ignore that for our purposes here.)

After taking on the task of reviewing new root CA certificates, and after some false starts, I settled on an interim policy of accepting new certificates only from CAs that had successfully completed a WebTrust for CAs audit or an equivalent third-party audit. Thus far I’ve approved several new CAs for inclusion under this policy. However I believe that this interim policy is not sufficient to address all of the issues around approval of new CAs (or review of existing ones), and thus I’ve gone through a public process in an attempt to create a more comprehensive policy. The current “1.0 Release Candidate” policy is the result of that process.

Features of the proposed policy: The new policy has several features that distinguish it from the current interim policy; I included these new features for the reasons stated below:

  • The policy explicitly expands the set of acceptable CA criteria beyond WebTrust to include three other sets of criteria, as noted in clause 8. The basic issue here is that the WebTrust for CAs criteria have the disadvantage of being tied to a particular commercial evaluation program sponsored by accounting professionals. Many CAs use alternative approachs to evaluation, for example being evaluated by government agencies under programs established national digital signature legislations. The new criteria provide alternatives to the WebTrust criteria; the ETSI criteria in particular are fully public, can be downloaded at no charge, and have no restrictions on who might use them for the purposes of evaluating CAs.

  • The policy adds some additional criteria beyond the criteria listed in clause 8, addressing security risks associated with particular CA practices (clause 4), technical problems related to CA practices (clause 4 again), and verification measures performed when CAs issue new certificates to their customers (clause 7). The issue here is that the WebTrust criteria and other criteria are not complete: They address how well a CA adheres to its own published policies, but they do not necessarily address the content of those policies. The result is that (at least in theory) a CA could pass a WebTrust or other audit even while engaging in practices that could negatively impact the security of typical users of our products. (To cite two extreme examples, a CA might have a published policy of issuing certificates without verification, or issuing certificates with obviously false information, with a third-party audit then simply confirming that the CA does indeed act in accordance with their stated policy.)

    There was consensus that we should do more to put a “floor” in place relating to acceptable CA practices, and the language in the policy represents the additional criteria on which there is currently consensus. (But see also the discussion below regarding open issues.)

  • The policy allows for alternative ways to evaluate that a CA has met the criteria noted above. This is related to expanding the acceptable criteria beyond those associated with the WebTrust for CAs program: With alternative criteria we have the possibility that CA evaluations might be done by people or organizations other than accounting firms or government-authorized test labs. The consensus is that there is no reason in principle not to accept the results of such evaluations, so long as there is sufficient information available for us to judge whether the evaluations have been done in a suitable manner. Clauses 9 and 10 outline how we evaluate the evaluators themselves, and thus determine whether or not to accept those evaluators’ evaluations of CAs.

    Note that in practice I believe that the number of “alternative” evaluations will be few, and will be mainly limited to nonprofit CAs and/or CAs associated with academic and research organizations. (There is at least one CA, CAcert.org, that might apply under this provision, and perhaps a couple of others as well.) Note also that the policy provides for the possibility that we might do our own CA evaluations (clause 11). I included this clause mainly for completeness, as we don’t currently have sufficient resources to do full CA evaluations; however it’s possible in the future that we might find one or more people willing to do this, in which case we could take advantage of clause 11 and have them act on our behalf.

  • The policy has some non-binding language relating to CAs maintaining separate roots (or separate intermediate CAs under a single root) in order to avoid issuing certificates according to different policies under the same CA. For more information on why this language was included (even though it’s non-binding) see the discussion below regarding open issues.

  • The policy has more details on how CAs should go about submitting requests (clause 14) and language confirming that issues relating to CA certificates will generally be handled in a manner consistent with practices elsewhere in the Mozilla project (clauses 15 and 16).

Open issues: There were some issues on which there were significant differences of opinion and a consequent lack of consensus on what the policy should contain:

  • There was significant disagreement concerning how far the policy should go in mandating how CAs verify people or organizations applying for certificates. In particular, with regard to SSL certificates some CAs offer “low assurance” certificates based on simply verifying that the applicant controls the domain name for which the certificate is being issued, as opposed to “higher assurance” certificates for which the CA also performs some additional measures to verify the applicant’s identity (e.g., checking personal identity documents, business licenses, etc.)

    Some people believe that such “low assurance” (or more neutrally, “domain-validated”) SSL certificates pose a undue risk to the security of typical users of our products; for example, phishers might obtain such certificates for their fake web sites and lead users to assume that because the sites are SSL-enabled that therefore they are legitimate. Other people (including myself) believe that issuance of lower-cost domain-validated certificates is a legitimate practice that does not pose undue risk to users and has the potential to expand use of SSL (and the protections it provides against certain types of attacks) beyond the minimal fraction of web sites that are currently SSL-enabled.

    Incidentally, even CAs themselves disagree on this issue; some CAs have publicly disparaged the use of domain-validated SSL certificates, while others have claimed that identity information in SSL certificates (beyond the domain name itself) is inherently unreliable and that using domain-validated certs can be a perfectly reasonable decision from a security point of view. For examples of such divergent views see the following references:

    We came to a consensus that the policy should mandate that CAs implement verification measures at least to the level used today for domain-validated SSL certificates; however there was no consensus for having the policy mandate implementation of additional verification measures beyond that (and thus require our rejecting CAs issuing domain-validated certificates).

  • Relating to the discussion above regarding domain-validated SSL certificates vs. “identity-validated” certificates, some people have proposed changing the browser UI to distinguish between certificates of different “assurance levels” and/or to provide more information about the CA and its policies (for example, to display a CA logo in addition to the simple lock icon). In connection with this some people proposed that the policy attempt to classify CAs into different categories based on the types of certificates they issue (e.g., “low assurance” vs. “high assurance”) and also mandate that CAs implement a standard way for us to distinguish such different classes of certificates.

    In particular, it was proposed that a CA not issue different types of certificates under the same root CA, but instead use different roots for different types of certificates. This would in theory provide one way to distinguish the types for purposes of the UI, and would also in theory allow us to disable acceptance of “low assurance” certificates (i.e., by removing the root CA certificates for CAs issuing such certificates) should we ever feel the need to do so, without affecting acceptance of “high assurance” certificates.

    I see several problems with this approach: First, there is no consensus on what if any changes we might want to make to the browser’s SSL UI, and no present commitment on anyone’s part to actually make such changes even if there were consensus. Second, there is not necessarily consistency between CAs on what constitutes a “high assurance” certificate versus a “low assurance” certificate, and thus it is not totally clear how we could go about making such a distinction ourselves. Finally, there are existing cases where CAs issue certificates of different types under the same root, and we would have to figure out if we could deal with these cases in a reasonable way (as opposed to treating all of the CA’s certificates as “low assurance” or just rejecting them entirely).

    Given the lack of consensus on this issue, I decided to include some language in the policy relating to CAs separating issuance of certificates of different types, thus highlighting the issue and our interest in it, but decided to make the language non-binding. I recommend that we learn more about what CAs are doing (or are likely to do) in this regard, and perhaps revisit this issue in the future.

Summary: I believe that the policy as it stands now is workable, is an improvement over the current interim policy, and reflects what consensus there exists regarding how we should handle CA certificates. I therefore recommend that you approve our adopting it as an official 1.0 policy.

If for some reason you don’t want to do that, here are your alternatives:

  • Adopt the policy with indicated changes.
  • Reject the policy entirely.
  • Postpone further work on the policy until we determine what if any changes we might make to the SSL UI and related security UI.

My preference is clearly for adopting the policy as is or with at most minor changes. I believe that the policy as proposed is a better policy than the current interim policy, and I believe that it is better to adopt a 1.0 policy now and revise it later than to postpone adoption of a policy awaiting code and UI changes that may never be made.

But in any event the decision is yours, and I look forward to hearing your comments on this matter. If you have further questions on the policy I’ll be glad to answer them.

Frank

P.S. I also plan to create a FAQ related to the CA certificate policy:

This is currently in an early state and is far from being complete. I’ll post more drafts of this as I finish them, however I don’t want to hold up the policy waiting on the FAQ.

I don’t know how long it will take to get the policy formally approved, with or without changes (or for that matter, whether it will get approved at all); I’ll post more information here and in n.p.m.crypto when something happens.