CA:Recommended Practices

From MozillaWiki
Jump to: navigation, search

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 non-English version may be authoritative (as that's the working language of the CA) but the CA is responsible for ensuring that the translation is not materially different from the authoritative version of the document.
  • 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.

CP/CPS Documents will be Reviewed!

During the public discussion phase, your CP/CPS documentation will be reviewed and commented on in the mozilla.dev.security.policy forum. Here are some examples of previous reviews of CP/CPS documents:

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.

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

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 Inclusion 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"

The CA's public documentation needs to provide sufficient information describing the steps taken by the CA to confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the domain name.

Baseline Requirements:

It is not sufficient to simply reference section 11.1.1 (section 3.2.2.4 in BR version 1.3) of the CA/Brower Forum's Baseline Requirements (BR). The BRs list several ways in which the CA may confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. Simply referencing section 11.1.1 (section 3.2.2.4 in BR version 1.3) of the BRs does not specify which of those options the CA uses, and is insufficient for describing how the CA conforms to the BRs. Section 8.2.1 (section 2 in BR version 1.3) of the BRs says: "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements."

WHOIS:

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.

It is not sufficient for the CP/CPS to just state that WHOIS is checked. The CP/CPS needs to have a high level description of how the WHOIS information is used. What information must match with that provided by the certificate subscriber? Is a phone call made or email sent to the technical or administrative contact field of the domain's WHOIS record? If an email is sent, does it include non-predictable information that the technical or administrative contact must use to respond?

Email Challenge-Response:

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.

CAs using this method of domain validation must ensure that they are using the full email, and that none of their systems misinterpret the localpart of an email. If your system fails to process the exact email, it will misinterpret the '+' sign as a delimiter. Consider, for example, the WHOIS contact information for a domain of "user+word@example.com" or "user=word@example.com". Both of these email addresses conform to the rules set out in RFC 822 with respect to the 'localpart' syntax. If your system emails to "word@example.com", rather than to the full "user+word@example.com" / "user=word@example.com", it will allow an attacker (who obtains "word@example.com") to cause and obtain certificates for example.com. Please work with your engineering department to ensure your systems properly handle such cases, as well as handling productions such as quoted-string, as also detailed in RFC 822 and subsequent RFCs. This is especially important as EAI addresses (described in RFC 6530 and related) come into play.

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 Inclusion 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 CA's public documentation needs to provide sufficient information describing how the email address is verified to be owned/controlled by the certificate subscriber. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the email address.

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.

It is not sufficient for the CP/CPS to just say that an email is sent to the customer. The CP/CPS needs to be clear that the RA sends email to the email address to be included in the certificate. The CP/CPS needs to be clear that the email shall contain some non-predictable information that the subscriber must then use or respond with to confirm that the owner of the email address actually received the email and responded.

Verifying Identity of Code Signing Certificate Subscriber

This section is no longer applicable.


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 Inclusion Policy states: “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; ”

There are various ways to confirm the certificate subscriber's identity and we don't dictate exactly how this should be done for non-EV certificates. However we must be clear that a minimum standard has been reached:

  1. The organizational information to be included in the cert had been verified.
  2. The identity of the individual (the person requesting the certificate) has been verified.
  3. If the request is on behalf of an organization, then the authority of the individual to make that request has been verified.
  4. The identity and organization validation are tied together so that there is reasonable assurance;
  5. Sufficient verification procedures are in place such that someone cannot submit forged or stolen documents and receive a certificate in his name (or that of a company).

The CA's public (and audited) documentation must provide sufficient information describing the process to permit us to form an opinion. The documentation needs to be clear about the checks that are performed to confirm the identity of the certificate subscriber as well as establish that the certificate subscriber is authorized by the organization to be referenced in the certificate.

If public resources are used, then there should be a description of the types of public resources that are used, what data is retrieved from public resources, and how that data is used for verification of the entity referenced in the certificate.

Verification procedures often include contacting the organization through an independent means to confirm that the certificate subscriber is authorized by the organization to request the certificate. If this is the case, then it should be stated. The documentation should include information such as how the company's contact information is obtained, the method for contacting the organization, the typical title/position of the person contacted at the organization, and what information they confirm. Note that if the CA issues certificates outside its national area, documentation will need to establish the same minimum standard outside borders.

Important: If the O in the Subject Field of the code signing certificate is not empty, then it should contain the subscriber's formal legal name that matches the name of the organization as per official government records in the subscriber's jurisdiction of its place of business. If an assumed name is used, the assumed name must be properly verified, and the legal name should also be included. For instance, the legal name may be appended in brackets.

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.

According to the CA/Browser Forum Baseline Requirements:

  • BR #9.2.1 (section 7.1.4.2.1 in BR version 1.3), Subject Alternative Name Extension
    • Required/Optional: Required
    • Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully-Qualified Domain Name or an iPAddress containing the IP address of a server.
  • BR #9.2.2 (section 7.1.4.2.2 in BR version 1.3) , Subject Common Name Field
    • Required/Optional: Deprecated (Discouraged, but not prohibited)
    • Contents: If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension (see Section 9.2.1 - or section 7.1.4.2.1 in BR version 1.3).

Domain owned by a Natural Person

Proposal from Varga Viktor: the exception when a natural person owns a domain name is not handled in any RFC. Its right, that the DNS to the CN is a deprecated solution, but the usage of the DNS in CN field is still popular. The question, how to display a natural person in a certificate. In EV it is solved, because EV can be bought only by organisation. CN cant be used, and the O field means organisation, not Individual.

If a domain name is owned by a natural person, then after successful validation of the parameters of the natural person, the SSL certificate should include information about the person in these fields:

  • O = name of the person in the form as displayed in its ID
  • OU = the string "natural person"

OCSP

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. Firefox and some other clients do not work with HTTPS OCSP responders, and many firewalls block requests that aren't over port 80, so OCSP responders must be accessible over HTTP (not only HTTPS) on port 80.

As per the CA/Browser Forum’s Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, the OCSP URI must be provided in the certificate, except when OCSP stapling is used. BR #13.2.2 (section 4.9.10 in BR version 1.3): "The CA SHALL update information provided via an Online Certificate Status Protocol..." From Appendix B (section 7.1.2 in BR version 1.3) regarding authorityInformationAccess in Subordinate CA Certificate and Subscriber Certificate: "With the exception of stapling ... this extension MUST be present ... and it MUST contain the HTTP URL of the Issuing CA’s OCSP responder..."

As per the CA/Browser Forum’s Guidelines for EV Certs, CAs must provide an OCSP capability for end-entity certificates that are issued after Dec 31, 2010. Mozilla is considering technical ways to enforce this OCSP requirement such that if Firefox cannot obtain a valid response from the OCSP responder, then the certificate will not be given EV treatment. (bug 585122)

OCSP service for end-entity certs must be updated at least every four days, and OCSP responses must have a maximum expiration time of ten days.

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 Firefox -> Preferences... -> Advanced -> Certificates
  • Check the box for "Query OCSP responder servers to confirm the current validity of certificates"
  • Close the popup
  • You may need to clear your history 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.

Network Security Controls

CAs must maintain current best practices for network security, and have qualified network security audits performed on a regular basis. The CA/Browser Forum has published a document called Network and Certificate System Security Requirements which should be used as guidance for protecting network and supporting systems.

It is expected that CAs do the following on a regular basis:

  • Maintain network security controls that at minimum meet the Network and Certificate System Security Requirements.
  • Check for mis-issuance of certificates, especially for high-profile domains.
  • Review network infrastructure, monitoring, passwords, etc. for signs of intrusion or weakness.
  • Ensure Intrusion Detection System and other monitoring software is up-to-date.
  • Confirm the ability to shut down certificate issuance quickly if alerted of intrusion.