This is the official Mozilla Foundation policy for CA certificates that the Mozilla Foundation and Mozilla Corporation distribute with our software products:

1. We will determine which CA certificates are included in software products distributed through mozilla.org, based on the benefits and risks of such inclusion to typical users of those products.
2. We will make such decisions through a public process, based on objective and verifiable criteria as described below.
3. We will not charge any fees to have a CA's certificate(s) distributed with our software products.
4. We reserve the right to not include a particular CA certificate in our software products, to discontinue including a particular CA certificate in our products, or to modify the "trust bits" for a particular CA certificate included in our products, at any time and for any reason. This includes (but is not limited to) cases where we believe that including a CA certificate (or setting its "trust bits" in a particular way) would cause undue risks to users' security, for example, with CAs that
   • knowingly issue certificates without the knowledge of the entities whose information is referenced in the certificates; or
   • knowingly issue certificates that appear to be intended for fraudulent use.

      This also includes (but again is not limited to) cases where we
      believe that including a CA certificate (or setting its "trust
      bits" in a particular way) might cause technical problems with the
      operation of our software, for example, with CAs that issue
      certificates that have
   

   • ASN.1 DER encoding errors;
   • invalid public keys (e.g., DSA certificates with 2048-bit primes, or RSA certificates with public exponent equal to 1);
   • duplicate issuer names and serial numbers;
   • incorrect extensions (e.g., SSL certificates that exclude SSL usage, or authority key IDs that include both the key ID and the issuer's issuer name and serial number); or
   • cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists.
5. We will consider adding certificates for additional CAs to the default certificate set upon request.
6. We require that all CAs whose certificates are distributed with our software products:
   • provide some service relevant to typical users of our software products;
   • publicly disclose information about their policies and business practices (e.g., in a Certificate Policy and Certification Practice Statement);
   • prior to issuing certificates, verify certificate signing requests in a manner that we deem acceptable for the stated purpose(s) of the certificates;
   • otherwise operate in accordance with published criteria that we deem acceptable; and
   • provide attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties with access to details of the CA's internal operations.
7. We consider verification of certificate signing requests to be acceptable if it meets or exceeds the following requirements:
   • for a certificate to be used for digitally signing and/or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf;
   • for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf;
   • for certificates to be used for digitally signing code objects, the CA takes reasonable measures to verify that the entity submitting the certificate signing request is the same entity referenced in the certificate or has been authorized by the entity referenced in the certificate to act on that entity's behalf;
   • for certificates to be used for and marked as Extended Validation, the CA complies with <a href="http://www.cabforum.org/EV_Certificate_Guidelines.pdf">Guidelines for the Issuance and Management of Extended Validation Certificates</a> (as modified by the <a href="http://www.cabforum.org/erratum.html">erratum</a> published by the CAB Forum) (or, for CA requests submitted on or before June 30, 2008, <a href="http://www.cabforum.org/EV_Certificate_Guidelines_draft11.pdf">draft 11 of these guidelines</a>), and has its compliance attested to in accordance with the requirements of Section J of that document.
   We reserve the right to use other requirements in the future.
8. We consider the criteria for CA operations published in any of the following documents to be acceptable:
   • Annex B, "(Normative) Certification Authority Control Objectives", of ANSI X9.79-1:2001, <a href="http://www.x9.org/standards/search/details?standard_key=3f63731c02c1074686aa37e0c1b43e72556d008f">Part 1: PKI Practices and Policy Framework</a>;
   • Clause 7, "Requirements on CA practice", in ETSI TS 101 456 V1.2.1 (2002-04) or later version, <a href="http://pda.etsi.org/pda/home.asp?wki_id=vRB.0b.A2uoprrwvH-WyI">Policy requirements for certification authorities issuing qualified certificates</a> (as applicable to either the "QCP public" or "QCP public + SSCD" certificate policies);
   • Clause 7, "Requirements on CA practice", in ETSI TS 102 042 V1.1.1 (2002-04) or later version, <a href="http://pda.etsi.org/pda/home.asp?wki_id=tmTZH@WhLn_.'0,.QCFnV">Policy requirements for certification authorities issuing public key certificates</a> (as applicable to any of the "NCP", "NCP+", or "LCP" certificate policies);
   • "WebTrust Principles and Criteria for Certification Authorities" in <a href="http://ftp.webtrust.org/webtrust_public/tpafile7-8-03fortheweb.doc">AICPA/CICA WebTrust Program for Certification Authorities, Version 1.0</a>; or
   • "WebTrust for Certification Authorities—Extended Validation Audit Criteria" in <a href="http://www.cabforum.org/WebTrustAuditGuidelines.pdf">WebTrust for Certification Authorities—Extended Validation Audit Criteria</a> (or, for CA requests received on or before June 30, 2008, the <a href="http://www.cabforum.org/WebTrustAuditGuidelines-Draft.pdf">November 20, 2006 draft of these criteria</a>) (in conjunction with "WebTrust Principles and Criteria for Certification Authorities").
   We reserve the right to accept other criteria in the future.
9. By "competent party" we mean a person or other entity who is authorized to perform audits according to the stated criteria (e.g., by the organization responsible for the criteria or by a relevant government agency) or for whom there is sufficient public information available to determine that the party is competent to judge the CA's conformance to the stated criteria. In the latter case the "public information" referred to should include information regarding the party's
   • knowledge of CA-related technical issues such as public key cryptography and related standards;
   • experience in performing security-related audits, evaluations, or risk analyses; and
   • honesty and objectivity.
10. By "independent party" we mean a person or other entity who is not affiliated with the CA as an employee or director and for whom at least one of the following statements is true:
    • the party is not financially compensated by the CA;
    • the nature and amount of the party's financial compensation by the CA is publicly disclosed; or
    • the party is bound by law, government regulation, and/or a professional code of ethics to render an honest and objective judgement regarding the CA.
11. We reserve the right to designate our own representative(s) to act as the competent independent party or parties described above, should that prove to be necessary and appropriate.
12. The burden is on the CA to prove that it has met the above requirements. However the CA may request a preliminary determination from us regarding the acceptability of the criteria and/or the competent independent party or parties by which it proposes to meet the requirements of this policy.
13. In addition to the requirements outlined above, we also recommend that CAs consider using separate root CA certificates with separate public keys (or separate intermediate CA certificates with separate public keys under a single root) when issuing certificates according to different Certificate Policies, so that we or others may selectively enable or disable acceptance of certificates issued according to a particular policy, or may otherwise treat such certificates differently (e.g., in our products' user interfaces). We reserve the right to make this a requirement in the future, and to not include a particular CA certificate in our software products, to discontinue including a particular CA certificate, or to modify the "trust bits" for a particular CA certificate, based on the CA's practices in this regard.
14. To request that its certificate(s) be added to the default set a CA should submit a formal request by submitting a <a href="https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=CA%20Certificates">bug report</a> into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "mozilla.org" product. The request should include the following:
    • the certificate data (or links to the data) for the CA certificate(s) requested for inclusion;
    • for each CA certificate requested for inclusion, whether or not the CA issues certificates for each of the following purposes within the CA hierarchy associated with the CA certificate:
      • SSL-enabled servers,
      • digitally-signed and/or encrypted email, or
      • digitally-signed executable code objects;
    • for each CA certificate requested for inclusion, whether the CA issues Extended Validation certificates within the CA hierarchy associated with the CA certificate and, if so, the EV policy OID associated with the CA certificate;
    • a Certificate Policy and Certification Practice Statement (or links to a CP and CPS) or equivalent disclosure document(s) for the CA or CAs in question; and
    • information as to how the CA has fulfilled the requirements stated above regarding its verification of certificate signing requests and its conformance to a set of acceptable operational criteria.

     We will reject requests where the CA does not provide such
     information within a reasonable period of time after submitting its
    

    request.
15. We will appoint a CA certificate "module owner" to evaluate CA requests on our behalf and make decisions regarding all matters relating to CA certificates included in our products. CAs or others objecting to a particular decision may appeal to mozilla.org staff, who will make a final decision.
16. We reserve the right to change this policy in the future. We will do so only after consulting with the public Mozilla community, in order to ensure that all views are taken into account.