CA/Required or Recommended Practices

CA Recommended Practices

This page contains a draft set of recommended practices for CAs wishing to have their root CA certificates included in Mozilla products. In some cases these practices are specified or implied by the Mozilla CA certificate policy and are mandatory for a CA to have its root certificate(s) included. In other cases the recommended practices are not mandatory per policy, but will help speed up a CA's application for inclusion and maximize the chances of its application being approved.

Publicly Available CP and CPS

CAs should supply the complete Certification Policy (CP) and Certification Practice Statement (CPS) containing sufficient information to determine whether and how the CA complies with the Mozilla policy requirements.

• The CP/CPS should be publicly available from the CA's official web site.
• The format of the CP/CPS document should be PDF or another suitable format for reading documents. CAs should not use Microsoft Word or other formats intended primarily for editable documents.
• The CP/CPS should be available in an English version.
• The CA should provide references to the CP/CPS sections (e.g., by section number and/or page number) that address the requirements of the Mozilla policy.

CA Hierarchy

A hierarchical structure of a single root with intermediate certs (subroots) is preferred. The single top-level root's public certificate is supplied for Mozilla's root list; the subroots are not. See CA:Recommendations_for_Roots

CAs that issue certificates under multiple subordinate CAs (i.e., under a root CA whose CA certificate is being requested for inclusion) or under multiple CA hierarchies (i.e., rooted at multiple root CAs, one or more of whose certificates is being requested for inclusion) should provide additional information as noted:

• The CA should provide a graphical or textual description of the CA hierarchy or hierarchies, including which subordinates are under which root CAs
• The CA should indicate the general types of certificates (i.e., for SSL/TLS servers, email signing/encryption, and code signing) issued by each subordinate CA under each root.
• Where a CP/CPS applies to multiple subordinate CAs and/or multiple CA hierarchies, the CA should indicate whether particular sections of the CP/CPS apply to different subordinates and/or hierarchies and, if so, what the differences are.

Audit Criteria

CAs should supply evidence of their being evaluated according to one or more of the criteria accepted as suitable per the Mozilla policy.

• The CA should indicate exactly which criteria they are being evaluated against (i.e., which of the criteria listed in the Mozilla policy).
• All documents supplied as evidence should be publicly available.
• Documents purporting to be from the CA's auditor (or other evaluator) should be available directly from the auditor (e.g., as documents downloadable from the auditor's web site).

Document Handling of IDNs in CP/CPS

If a CA allows the use of internationalized domain names (IDNs) in certificates (e.g., as issued for SSL/TLS-enabled servers), the CA should address the issue of homographic spoofing of IDNs in their CP/CPS, even if primary responsibility for dealing with this issue falls on domain registries. (This doesn't mean that the CAs must prevent such spoofing. It merely means that a CA should describe how it handles the issue of spoofing when authenticating the owner of a domain.)

Revocation of Compromised Certificates

CAs should revoke certificates with private keys that are known to be compromised, or for which verification of subscriber information is known to be invalid.

Verifying Domain Name Ownership

We rely on public documentation and audits of those documented processes to ascertain that the requirements of section 7 of the Mozilla CA Certificate Policy are met.

Section 7 of the Mozilla CA Certificate Policy states: “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"

WHOIS is used by some CAs as a source of information for checking ownership/control of the domain name for SSL certificate applications. WHOIS information may be subject to compromise. CAs are responsible for implementing appropriate methods to reduce the risk of compromise. For example, direct command line, HTTPS to the original registrar, or correlating multiple sources. The CA should include information in their CP/CPS about the method that they use to validate the integrity of the data.

Many CAs use an email challenge-response mechanism to verify that the SSL certificate subscriber owns/controls the domain to be included in the certificate. Some CAs allow applicants to select an address from a predetermined list to be used for this verification. See Mozilla's restrictions on the set of verification addresses that may be used.

Verifying Email Address Control

We rely on public documentation and audits of those documented processes to ascertain that the requirements of section 7 of the Mozilla CA Certificate Policy are met.

Section 7 of the Mozilla CA Certificate Policy states: “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”

The recommended way to satisfy this requirement is to perform a challenge-response type of procedure in which the CA sends email to the email address to be included in the certificate, and the applicant must respond in a way that demonstrates that they have control over that email address. For instance, the CA may send an email to the address to be included in the certificate, containing secret unpredictable information, giving the applicant a limited time to use the information within.

DNS names go in SAN

Some CAs mistakenly believe that one primary DNS name should go into the Subject Common Name and all the others into the SAN. That's wrong. ALL should go into the SAN.

OCSP

Mozilla strongly recommends that OCSP be provided for certificates chaining to CAs that are included in NSS. OCSP responders should be set up to listen on a standard port (e.g. port 80), because firewalls may block ports other than 80/443.

CAs are expected to comply with the current EV Guidelines of the CA/B Forum.

Section 11.1.1 of version 1.2 of the EV Guidelines says: It is strongly RECOMMENDED that all CAs support OCSP when a majority of deployed Web servers support the TLS 1.0 extension in accordance to RFC 3546, to return “stapled” OCSP responses to EV-enabled applications. CAs MUST support an OCSP capability for Subscriber Certificates that are issued after Dec 31, 2010.

RFC 2560, sections 2.2, 2.6, 3.2 and 4.2.2.2 define the requirements for the OCSP response signer's certificate and certificate chain. NSS enforces these requirements exactly.

You MUST test your OCSP service in Firefox! We expect OCSP responders to function without error in Mozilla products. To test in Firefox:

• Go to Tools -> Options -> Advanced -> Encryption -> Validation
• Check the box for "When an OCSP server connection fails, treat the certificate as invalid"
• You may need to clear your cache
• Browse to a website whose SSL certificate chains up to your root and has the corresponding OCSP URI in the AIA extension.

Errors that CAs sometimes encounter when testing OCSP in Firefox:

• Error code: sec_error_ocsp_unauthorized_response
  • Please read section 4.2.2.2 "Authorized Responders" on pages 10-11 of RFC 2560. CAs that emit certificates for the general public must use a configuration that conforms to either rule 2 or 3. NSS also supports rule 1, but it requires manually configuring Firefox to set the trusted OCSP responder. This makes this choice relevant only when the Firefox installation is part of a centralized deployment where a local OCSP responder has been setup to send back OCSP responses for all the CAs that are locally trusted. The IETF pkix group that authored RFC 2560 has confirmed that rule 1 is intended to cover similar situations and not public deployments.
• Error code: sec_error_ocsp_bad_http_response
  • the http response from the OCSP responder had some result code other than 200.
  • The http 200 response from the OCSP responder could not be decoded.
• Error code: sec_error_ocsp_invalid_signing_cert
  • OCSP response signer's certificate was issued by the CA that issued the certificate whose status is being checked, but the response signer's certificate does not bear an ExtendedKeyUsage extension with the OCSP Responder OID, or
  • OCSP response signer's certificate chain does not validate (e.g. expired, or bad signature, etc.)
  • Trusted OCSP Responder Signing cert has not been imported. Mozilla users should not have to find and install the OCSP responder's certificate. See Potentially Problematic Practices.
• Error code: sec_error_bad_database
  • the OCSP response gives a cert subject name to identify its signer's certificate, but no certificate by that name can be found -- not in the response, not in the database, and not in the cert chain of the certificate whose status is being checked. See this bugzilla bug for more details.

Notes for future work

• What (if anything) should we do regarding the use of non US-ASCII character sets in certs? To what extent is this supported today in NSS and by CAs? This whole problem seems analogous to the IDN problem.
  • Excluding the IDN problem (on which I comment under "Document Handling of IDNs in CP/CPS"), care should be taken to avoid setting technical requirements more stringent than the X.509 specifications. If X.509 permits non-US-ASCII characters in certificates and if NSS and the Mozilla products that use it can operate correctly in the presence of such characters, they should be permitted. On the other hand, if non-US-ASCII characters cause technical problems for NSS or the Mozilla products that use it, that is already addressed under item #4 (after the first two bullets) in the existing policy. Of course, it might be appropriate to add a new bullet in the second set of bullets under item #4 to state explicitly that certificates must not contain any characters that cause software failures or security vulnerabilities in Mozilla products. As an alternative, characters might be limited to those used in languages for which Mozilla products have been localized.