CA/External Sub CAs
Contents
Externally Operated Subordinate CAs
While intermediate certificates (aka subordinate CA certificates) play a critical role by directly signing TLS and email certificates, they can impact security in the same way that a directly-included root certificate can if they are not technically constrained. Therefore, they must be held to the same level of accountability as root certificates.
In keeping with our commitment to the security and privacy of individuals on the internet, Mozilla is increasing our oversight of publicly trusted intermediate CA certificates, and in particular externally-operated subordinate CAs and cross-certified CAs. An externally-operated subordinate CA is an organization that physically controls the private key of the subordinate CA certificate and/or performs their own domain validation for domains to be included in the end-entity certificate without verification of the domains being done by the root CA operator.
As stated in MRSP section 8.4, the operator of a Mozilla-trusted root CA is at all times completely and ultimately accountable for every certificate signed under the root CA, whether directly or through subordinate CAs or cross-certified CAs. The operator of the root CA must ensure that each subordinate CA within their CA hierarchy fully and continually complies with requirements.
Process for non-Technically-Constrained Subordinate CAs
The root CA operator MUST complete the following process and receive written approval from Mozilla before a non-technically-constrained (according to MRSP section 5.3) externally-operated subordinate CA begins issuing certificates under the conditions stated in section 8.4 of MRSP.
This approval process is essentially the same approval process used for root inclusion requests, with the main difference being that the root CA operator collects the information from the potential subordinate CA operator, creates a corresponding Bugzilla Bug, and provides the results of their own detailed review. Then a Mozilla representative or a CA Community representative (as agreed by the Mozilla representative) will perform an additional detailed review of the subordinate CA’s CP/CPS and audit documents and provide their findings in the Bugzilla Bug. Then a representative of Mozilla starts a discussion in MDSP as described in the Public Discussion section below.
Approval of one type of certificate issuance (e.g. email) for a subordinate CA operator does not imply that another type of certificate issuance (e.g. TLS) would be approved for the same CA operator.
A subordinate CA operator only needs to go through this process once for each type of certificate issuance, even if they will be operating multiple subordinate CA certificates, provided that they are operating under the same set of policies and audits.
| Step | Who performs this step | Equivalent Step(s) in Mozilla’s root Inclusion Process |
|---|---|---|
| Create a Bugzilla Bug containing the required documentation about the potential subordinate CA operator | Root CA Operator | 1 and 2 |
| Perform a detailed review of the potential subordinate CA’s policy and audit documents, and provide findings in the Bugzilla Bug. The potential Subordinate CA operator may update their documentation based on the Root CA operator’s findings, and this step may be re-performed. | Root CA Operator | 3 |
| Update the Bugzilla Bug to indicate that it is ready for Mozilla review. Set "Whiteboard" to "[subca-cps-review]" and Set "Request Information From" to bwilson@mozilla.com | Root CA Operator | |
| Perform a detailed review of the potential subordinate CA’s policy and audit documents, provide and summarize the findings in the Bugzilla Bug. | Representative of Mozilla
or of the CA Community (as agreed by a Mozilla representative) |
3 |
| Start a public discussion in MDSP summarizing the request and providing links to documentation and evaluations. | Representative of Mozilla | 4 |
| Discussion proceeds and the root CA Operator or the potential subordinate CA operator responds to questions and concerns | Root CA Operator or potential subordinate CA operator | 5, 6, 7, 8 |
| State Decision in the discussion thread and in the Bugzilla Bug | Representative of Mozilla | 9, 10
(Steps 11-17 are not relevant to intermediate certificates) |
| Add the subordinate CA certificate(s) to the CCADB, if it was not previously added according to MRSP section 5.3.** | Root CA Operator | 18 |
| Update the appropriate fields for the CA certificate(s) in the CCADB to indicate that public discussion occurred and that the CA was approved | Representative of Mozilla | |
| Update the corresponding records in the CCADB at least annually with current policy and audit documentation. | Root CA Operator |
** Public disclosure of new CA certificates in the CCADB must occur within one week of signing as required by MRSP § 5.3.2, including an indication of whether the CA is covered by the same audits as the parent CA or whether it has a separate audit.
Bugzilla Bug
Create a new Bugzilla Bug report corresponding to your request.
● https://bugzilla.mozilla.org/enter_bug.cgi
● Product: NSS
● Component: CA Certificate Root Program
● Type: task
● Severity: enhancement
● Summary: <your CA's name>: New Subordinate CA Request
Do NOT select the check boxes to restrict visibility, such as making it confidential or marking it as a security bug. All information that is submitted must be publicly available.
Required Documentation
The following information must be provided by the root CA operator about the potential subordinate CA.
1. Full Legal Name
2. Website URL
3. Expected CA hierarchy under the subordinate CA
4. Certificate profile for the subordinate CA certificate
5. CP, CPS, or CP/CPS for the operation of the subordinate CA
6. Audit statements, auditor information and qualifications
- May be uploaded as an attachment to the Bugzilla Bug
- Subordinate CA audits must follow the same audit rules as for root CAs, as per MRSP section 3
- If the subordinate CA is new, a point-in-time audit statement may be initially used
- If key generation has already occurred, then the root CA operator should provide a copy of the relevant auditor-supplied documentation (e.g. a key generation report).
7. The subordinate CA’s Compliance Self-Assessment
8. The results of the root CA operator’s detailed policy and audit review for the subordinate CA
9. Explanation about why this subordinate CA is needed, e.g. Value Justification. For example, the primary reason in the explanation can be that:
- a large enterprise wants to manage the certificates for domains that they own, or
- the CA certificate is for a new root CA operator who wishes to be cross-signed in order to provide ubiquity across browsers after their root certificate has been approved for inclusion in Mozilla’s root store.
Public Discussion
Prior to public discussion on the Mozilla dev-security-policy mailing list, the root CA operator must attest that it has verified all of the required documentation. A Representative of Mozilla or of the CA Community (as agreed by a Mozilla representative) will perform a separate and independent detailed review of the potential subordinate CA’s policy and audit documents, and provide findings in the Bugzilla Bug before starting the discussion.
If Mozilla approves the subordinate CA operator, a representative of Mozilla will:
● Add a statement of approval in the Bugzilla Bug and in the public discussion
● Indicate in the appropriate fields of the CCADB that the public discussion process has taken place and that it has been approved as an externally operated CA.
Issuance of end entity certificates from the subordinate CA may then commence.
If the subordinate CA is rejected, then any corresponding existing certificates issued by the root CA to the subordinate CA operator will be added to OneCRL.
Technically-Constrained Subordinate CAs
TBD
