CA/External Sub CAs: Difference between revisions

== 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 an unconstrained subCA certificate for use by an external, third-party operator that has not previously undergone Mozilla's 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 [https://groups.google.com/a/mozilla.org/g/dev-security-policy Mozilla dev-security-policy mailing list].  

The process outlined herein applies to root CA operators intending to sign a new subCA certificate that will grant the subCA operator the ability to issue certificates that they were not previously capable of issuing. Specifically, this process must be followed when an organization will gain control of a subCA certificate that grants the subCA operator the new ability to issue S/MIME, TLS certificates, or EV TLS certificates. For example, if the prior review/approval of the subCA was only for email certificates, and the subCA operator now wants to issue server certificates, then this process will need to be performed by the root CA operator signing that subCA.

The process outlined herein does not apply when new certificate-issuance capabilities are not being introduced, and:

* both CA operators are already in the Mozilla root program; or

* the new subCA certificate is to be issued to a subCA operator who has already undergone this process.

'''Applicable Policy Provisions'''

* [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#313-audit-parameters MRSP § 3.1.3] - CAs must be audited, at least annually with no gaps, beginning with CA key pair generation.

* [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#71-inclusions MRSP § 7.1] - CAs must provide evidence that their CA certificates fully comply with the current MRSP and Baseline Requirements, and have continually, from the time of CA, the then-current Mozilla Root Store Policy and Baseline Requirements.  

* [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#8-ca-operational-changes MRSP § 8] - CAs cannot assume that trust is transferable. 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 [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#53-intermediate-certificates MRSP section 5.3]) that directly or transitively chains to the CA's included certificate(s).

* [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#81-change-in-legal-ownership MRSP § 8.1] - A receiving or acquiring company must demonstrate compliance with the MRSP and there must be a public discussion regarding admittance to the root program.

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 [https://groups.google.com/a/mozilla.org/g/dev-security-policy 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 [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited 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.

Before subCA creation or at the latest one week following subCA creation, a bug should be created in [https://bugzilla.mozilla.org/home 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.  

Prior to public discussion, the root CA operator must confirm that it has verified all of the following information, '''which must be provided for public review in, or as attachments to, the Bugzilla bug''' when the root CA operator starts the public discussion on the [https://groups.google.com/a/mozilla.org/g/dev-security-policy Mozilla dev-security-policy mailing list]:

1. External Third Party’s Full Legal Name;

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's review of the subCA operator’s practices (e.g. the CP and CPS), including the completed [[CA/Compliance_Self-Assessment|Compliance Self-Assessment]].

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 [https://crt.sh/mozilla-onecrl OneCRL].