CA/External Sub CAs not Technically Constrained

< CA


Process for Review and Approval of Externally Operated Subordinate CAs that are Not Technically Constrained


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 (subCAs). It is responsible to ensure that each subCA fully and continually complies with requirements.

When a root CA operator intends to sign a subCA certificate for use by an external, third-party operator that has not previously undergone this review process for the type of certificate that it will be authorized to issue, the root CA operator is responsible for collecting information and performing due diligence similar to that performed by Mozilla on root inclusion requests (i.e. Quantifying Value and other steps not outlined in this wiki page would not be required), and for initiating the public discussion on the Mozilla dev-security-policy mailing list.

Following public discussion, the Mozilla CA Program Manager will determine whether the subCA operator will be accepted, and update the corresponding CCADB record to indicate the result.

The process outlined herein applies to CA operators that either do not already operate a subCA that is trusted by the Mozilla root program, or already operate within the root program, but seek a new subCA certificate that will grant them technical capability to issue kinds of certificates that they previously did not have. Specifically, this process must be followed when an organization does not control a subCA certificate with capability to issue certificates of one or more of the following types and the new subCA certificate will grant such capability: S/MIME (Email trust bit), (DV/IV/OV) TLS Server Authentication (Websites trust bit), and/or EV TLS Server Authentication (Websites trust bit with EV-enablement).

The process outlined herein applies to subCA operators not already in the Mozilla root program, or that have not been previously approved for the type of certificate that they will be capable of issuing. A different procedure would be followed, for instance, when two CA operators already in the Mozilla root program are creating a cross certificate for solely for interoperability or ubiquity. And, if a new or modified CA certificate is to be issued to the same third-party CA operator that has already undergone the full process for the type of end entity certificates being issued, then there is no need to repeat this process (e.g. for renewals or replacements of the subCA certificate). However, if the prior process only reviewed issuance of email certificates, and the CA operator then wants a CA certificate with the serverAuth EKU in order to issue server certificates, then that part of the review process not fully performed must be repeated because of the different requirements and performance expectations. And vice versa, if the CA operator were first approved to issue server certificates and then wanted a CA certificate with the emailProtection EKU to issue email certificates, then any relevant part of the review process that was missed would need to be performed.

Applicable Policy Provisions

Section 3.1.3 of the Mozilla Root Store Policy (MRSP) requires CAs to be audited, at least annually with no gaps, beginning with CA key pair generation. Section 7.1 says, “CAs MUST provide evidence that their CA certificates fully comply with the current Mozilla Root Store Requirements and Baseline Requirements, and have continually, from the time of CA private key creation, complied with the then-current Mozilla Root Store Policy and Baseline Requirements.”

MRSP section 8 requires that root CA operators notify Mozilla when a new third party is going to operate a trusted CA outside the confines of the CA operator’s existing operations.

According to MRSP § 8, CAs cannot assume that trust is transferable. "All CAs whose certificates are included in Mozilla's root program MUST notify Mozilla if: . . . an organization other than the CA obtains control of an unconstrained intermediate certificate (as defined in section 5.3.2 of this policy) that directly or transitively chains to the CA's included certificate(s) . . . . CAs should err on the side of notification if there is any doubt. Mozilla will normally keep commercially sensitive information confidential. Throughout any change, CA operations MUST continue to meet the requirements of this policy. . . . CAs are encouraged to notify in advance in order to avoid unfortunate surprises."

MRSP § 8.1 states that the receiving or acquiring company "must demonstrate compliance with the entirety of this policy and there MUST be a public discussion regarding their admittance to the root program, which Mozilla must resolve with a positive conclusion in order for the affected certificate(s) to remain in the root program. If the entire CA operation is not included in the scope of the transaction, issuance is not permitted until the discussion has been resolved with a positive conclusion."

Process Overview

Information gathering, due diligence, and public discussion should all happen before the signing of the subCA certificate. Prior to signing the subCA, the root CA operator should collect and verify the required documentation, as it becomes available, set forth in the numbered list below, and conduct the public discussion on the Mozilla dev-security-policy mailing list.

The public discussion phase should occur prior to the signing of the subCA. However, current policy permits public discussion to occur following signing. 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, a key protection report, a point-in-time audit, or a period-of-time audit). If public discussion occurs prior to signing the subCA, then audit documentation should be submitted by the root operator as soon as it becomes available.

In any event, public disclosure of the subCA in the CCADB must occur within one week as required by MRSP MRSP § 5.3.2, including an indication of whether the subCA is covered by the same audits as the parent CA or whether it has a separate audit, and Mozilla’s prior approval is required because discussion must be “resolved with a positive conclusion” before issuance of any end entity certificates.

Required Documentation

Before subCA creation or at the latest one week following subCA creation, a bug should be created in Bugzilla under the NSS Product with a component of “CA Certificate Root Program”.

The root CA operator must provide audit statements for the subCA operator, which should be uploaded to the bug in Bugzilla and referenced in the subCA’s record in the CCADB.

SubCA audits must follow the same audit rules as for root CAs. If the subCA is new, root CA operator need only supply a point-in-time audit statement to Mozilla prior to approval. The new subCA certificate must appear in subsequent period-of-time audit statements, but is not required to appear on the statements submitted to Mozilla for approval, so long as the root CA asserts that the subCA will be operated within the scope of the supplied audit statements.

Prior to public discussion, the root CA operator must confirm that it has verified all of the following information, which must be provided when the root CA operator starts the public discussion in Mozilla’s dev-security-policy mailing list:

1. External Third Party’s Full Legal Name;

2. External Third Party’s Website URL;

3. Expected CA hierarchy under the subCA;

4. Audit documentation, as explained above;

5. Links to the subCA’s current CP/CPS; and

6. The root CA operator must review the subCA operator’s practices, CP/CPS, and completed Compliance Self-Assessment for required and prohibited practices.

After a minimum of 3 weeks have passed, a Mozilla representative will announce a one-week “last call” for objections. Mozilla may determine to extend public discussion, or approve or reject the subCA operator. If the subCA operator is approved, Mozilla will 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 subCA may then commence. If the subCA is rejected, then any existing subCA certificate will be added to OneCRL.