- 1 Potentially Problematic CA Practices
- 1.1 Delegation of domain/email validation to third parties
- 1.2 Allowing external entities to operate subordinate CAs
- 1.3 Distributing generated private keys in PKCS#12 files
- 1.4 OCSP Responses signed by a certificate under a different root
- 1.5 Generic names for CAs
- 1.6 Lack of communication with end users
- 1.7 Backdating the notBefore date
Potentially Problematic CA Practices
This page contains draft comments about various CA practices that have been the subject of discussion in past CA evaluations. In general these practices are not explicitly addressed by the Mozilla CA certificate policy, and are not always security risks. However we want to highlight them because they've occasioned controversy in the past and have in some cases caused approval of applications to be delayed. Some of these practices may be addressed in future versions of the policy.
Delegation of domain/email validation to third parties
Domain and Email validation are core-requirements of the Mozilla CA Policy and should always be incorporated into the issuing CAs procedures whenever possible. Registration Authorities (RA) or other third parties performing such functions must provide attestations about their procedures and/or should be audited together with the issuing CA. The CA must demonstrate clear and efficient controls attesting the performance of its RAs. Delegation of domain/email validation to third parties should generally be avoided.
Allowing external entities to operate subordinate CAs
Some CAs authorize external entities to operate their own CAs as subordinate CAs under the original CA's root. This raises concerns relating to whether or not such external entities are audited in a manner equivalent to the root CA, as well as what legal and technical arrangements constrain the external entities.
Where a root from a CA signs an intermediate certificate used by an external CA to then sign subsidiary intermediate certificates or subscriber certificates, that situation needs to be disclosed. That disclosure should include documentation of what requirements are imposed by the CA owning the root upon the operations of external CAs. Further, the public audit report for the CA owning the root must indicate how and when the operations of the external CAs have been reviewed for compliance with those documented requirements.
You must provide a clear description of the subordinate CAs that are operated by external third parties, and an explanation as to how the CP/CPS and audits ensure the third parties are in compliance with Mozilla's CA Certificate Policy requirements as per the Subordinate CA Checklist.
Distributing generated private keys in PKCS#12 files
It is reported that some CAs generate the key pairs for their subscribers, rather than having the subscribers generate their own key pairs, and once generated, those CAs distribute the private key, together with the issued public key certificate and its chain, to the subscriber in a PKCS#12 file. The issues include:
- The user doesn't know or control who else possesses and can use his private key (decrypt his private messages or forge his signature), and
- The distribution channels used (e.g. unencrypted email) may not be adequately secured.
CAs must never generate the key pairs for signer or SSL certificates. CAs may only generate the key pairs for SMIME encryption certificates. Distribution or transfer of certificates in PKCS#12 form through unsecure electronic channels is not allowed. If a PKCS#12 file is distributed via a physical data storage device, then
- The storage must be packaged in a way that the opening of the package causes irrecoverable physical damage. (e.g. a security seal)
- The PKCS#12 file must have a sufficiently secure password, and the password must not be transferred together with the storage.
OCSP Responses signed by a certificate under a different root
CAs who issue certificates with OCSP URLs in AIA extensions should make sure that the OCSP responses conform to RFC 2560, and work correctly for Mozilla users without requiring the user to find and install the OCSP responder's certificate, that is, the certificate with which the OCSP response signatures are verified.
RFC 2560, sections 2.2, 2.6, 3.2 and 188.8.131.52 define the requirements for the OCSP response signer's certificate and certificate chain. NSS enforces these requirements exactly.
When an OCSP responder URL is included in end-entity certificates, Firefox will by default attempt to check the certificate's status via OCSP. If the OCSP signer certificate is not the certificate of the CA that issued the certificate in question and is not issued by the CA that issued the certificate in question, the OCSP check will fail with an NSS error code for OCSP, such as SEC_ERROR_OCSP_UNAUTHORIZED_REQUEST or SEC_ERROR_OCSP_UNAUTHORIZED_RESPONSE.
For a detailed explanation about why an OCSP responder should not use a self-signed OCSP responder certificate and depend on Trusted Responder Mode within the Firefox browser, see: Details about OCSP Trusted Responder Mode.
Please test your OCSP responder within the Firefox browser by enforcing OCSP as per our CA Recommended Practices for OCSP.
Generic names for CAs
In various contexts Firefox and other Mozilla-based products display to users the names of root CAs, issuing CAs, and intermediate CAs in general. In some cases CA names are very generic, e.g., "Secure Server CA"; this makes it difficult for users to ascertain who operates the CA without undertaking a detailed investigation.
Our recommendation is that all CA names incorporate an organizational name or product brand name sufficiently unique to allow relatively straightforward identification of the CA.
Additionally, the issuer and subject information in the root certificate should provide clear indication about who owns or operates the certificate. Generic issuer and subject information inhibits the users' ability to establish a chain of trust, and to pursue complaints when appropriate. For instance, the following issuer information would not be acceptable in a root certificate to be included in NSS.
- CN = Root CA
- OU = Certification Authorities
- OU = Services
- O = admin
There is no information in this issuer that can be linked back to any particular CA. There is no distinguishable company name or brand name. All of the information in this issuer is too generic to do a search on and hope to find the CA.
Important: Both the O and the CN must be meaningful, and not generic terms such as "admin" or "root". It is not acceptable to have the O be a generic term such as "Admin" because it could mislead users that rely on the issuer details, such as when you hover your mouse over the domain or organization section in the address bar.
Lack of communication with end users
CAs should be contactable by, and accept and act upon complaints made by, those relying on their assertions of identity. For CAs included in Mozilla, this will include being responsive to members of the general public, including people who have not purchased products from that CA.
Backdating the notBefore date
Certificates do not contain an issue timestamp, so it is not possible to be certain when they were issued. The notBefore date is the start of the certificate's validity range, and is set by the CA. It should be a reasonable reflection of the date on which the certificate was issued. Minor tweaking for technical compatibility reasons is accepted, but backdating certificates in order to avoid some deadline or code-enforced restriction is not.