CA/External Sub CAs: Difference between revisions

From MozillaWiki
< CA
Jump to navigation Jump to search
m (Bwilson moved page CA/External Sub CAs not Technically Constrained to CA/External Sub CAs: Change of focus)
 
(14 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Process for Review and Approval of Externally Operated Subordinate CAs that are Not Technically Constrained ==
= Externally Operated Subordinate CAs =


=== Summary ===
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.


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.
In keeping with our commitment to the security and privacy of individuals on the internet, Mozilla is [https://blog.mozilla.org/security/2021/12/09/improved-quality-of-intermediate-certificates-with-enhanced-oversight-and-automation/ 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.


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].  
As stated in [https://www.mozilla.org/projects/security/certs/policy/ 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.


Following public discussion, the Mozilla CA Program Manager will determine whether the subCA operator will be accepted, and update the corresponding [https://www.ccadb.org/ CCADB] record to indicate the result.
== Process for non-Technically-Constrained Subordinate CAs ==


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 root CA operator MUST complete the following process and receive written approval from Mozilla before a non-technically-constrained (according to [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#53-intermediate-certificates MRSP section 5.3]) externally-operated subordinate CA begins issuing certificates under the conditions stated in section 8.4 of [https://www.mozilla.org/projects/security/certs/policy/ MRSP].


The process outlined herein does not apply when new certificate-issuance capabilities are not being introduced, and:
This approval process is essentially the same approval [[CA/Application_Process#Process_Overview|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 three-week discussion in [https://groups.google.com/a/mozilla.org/g/dev-security-policy MDSP] or in the [https://groups.google.com/a/ccadb.org/g/public CCADB Public list] as described in the [[CA/External_Sub_CAs#Public_Discussion|Public Discussion]] section below.
* 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'''
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.


* [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.
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.


* [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.
{| class="wikitable"
|-
! '''Step''' !! Who performs this step !! Equivalent Step(s) in Mozilla’s root Inclusion Process
|-
| Create a [[#Bugzilla_Bug|Bugzilla Bug]] containing the [[#Required_Documentation|required documentation]] about the potential subordinate CA operator || Root CA Operator || 1 and 2
|-
| Perform a [[CA/Application_Verification#Detailed_Review|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. Then provide a summary of the detailed policy review, audit documents, and other findings in the Bugzilla Bug. || Root CA Operator || 3
|-
| Start a [[CA/External_Sub_CAs#Public_Discussion|3-week public discussion]] in [https://groups.google.com/a/mozilla.org/g/dev-security-policy MDSP] or [https://groups.google.com/a/ccadb.org/g/public CCADB Public] summarizing the request and providing links to the documentation and evaluations performed. || Root CA Operator || 4
|-
| Discussion proceeds, and the root CA Operator and the externally-operated subordinate CA operator respond to questions and concerns || Root CA Operator and subordinate CA operator || 5 
|-
| Summarize the results of the discussion and provide decision in the discussion thread and in the Bugzilla Bug || Representative of Mozilla || 6, 7
(Steps 8-14 are not relevant to intermediate CA certificates)


* [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).
|-
| Add the subordinate CA certificate(s) to the CCADB, if it was not previously added according to [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#53-intermediate-certificates MRSP section 5.3].** || Root CA Operator || 15
|-
| 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 ||
|}
<nowiki>**</nowiki> Public disclosure of new CA certificates in the CCADB must occur within seven days of signing the CA certificate 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 CA is covered by the same audits as the parent CA or whether it has a separate audit.


* [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#8-ca-operational-changes MRSP § 8] - Root CA operators must notify Mozilla when a new third party is going to operate a trusted CA outside the confines of the CA operator’s existing operations.
== Bugzilla Bug ==


* [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.
[https://bugzilla.mozilla.org/enter_bug.cgi?&component=CA%20Certificate%20Root%20Program&product=CA%20Program&short_desc=(Your%20CA's%20name)%20New%20Subordinate%20CA%20Request Create a new Bugzilla Bug report] corresponding to your request.


=== Process Overview ===
● https://bugzilla.mozilla.org/enter_bug.cgi


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].
● Product: CA Program


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.
● Component: CA Certificate Root Program


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.
● Type: task


=== Required Documentation ===
● Summary: &lt;your CA's name&gt;: New Subordinate CA Request


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”.  
Do NOT select the checkboxes to restrict visibility, such as making it confidential or marking it as a security bug. All information that is submitted must be publicly available.


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.
== Required Documentation ==


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.  
The following information must be provided by the root CA operator about the potential subordinate CA.


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. Full Legal Name


1. External Third Party’s Full Legal Name;
2. Website URL
 
2. External Third Party’s Website URL;


3. Expected CA hierarchy under the subCA;
3. Expected CA hierarchy under the subordinate CA


4. Audit documentation, as explained above;
4. Certificate profile for the subordinate CA certificate


5. Links to the subCA’s current CP/CPS; and
5. CP, CPS, or CP/CPS for the operation of the subordinate CA


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]].
6. Audit statements, [[CA/Audit_Statements#Providing_Auditor_Qualifications|auditor information and qualifications]]
<ol style="list-style-type:lower-alpha">
<li>May be uploaded as an attachment to the [[CA/External_Sub_CAs#Bugzilla_Bug|Bugzilla Bug]]</li>
<li>Subordinate CA audits must follow the same audit rules as for root CAs, as per [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#3-documentation MRSP section 3]</li>
<li>If the subordinate CA is new, a point-in-time audit statement may be initially used</li>
<li>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).</li>
</ol>
7. The subordinate CA’s [[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].
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. [[CA/Quantifying_Value|Value Justification]]. For example, the primary reason in the explanation can be that:
<ol style="list-style-type:lower-alpha">
<li>a large enterprise wants to manage the certificates for domains that they own, or</li>
<li>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.</li>
</ol>
== Public Discussion ==
 
Prior to public discussion on the [https://groups.google.com/a/mozilla.org/g/dev-security-policy Mozilla dev-security-policy mailing list] or the [https://groups.google.com/a/ccadb.org/g/public CCADB Public list], the root CA operator must attest that it has verified all the [[CA/External_Sub_CAs#Required_Documentation|required documentation]]. A Representative of Mozilla or of the CA Community (as agreed by a Mozilla representative) will perform a separate and independent [[CA/Application_Verification#Detailed_Review|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 [https://crt.sh/mozilla-onecrl OneCRL].
 
= Technically-Constrained Subordinate CAs =
 
TBD

Latest revision as of 22:26, 11 September 2025

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 three-week discussion in MDSP or in the CCADB Public list 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. Then provide a summary of the detailed policy review, audit documents, and other findings in the Bugzilla Bug. Root CA Operator 3
Start a 3-week public discussion in MDSP or CCADB Public summarizing the request and providing links to the documentation and evaluations performed. Root CA Operator 4
Discussion proceeds, and the root CA Operator and the externally-operated subordinate CA operator respond to questions and concerns Root CA Operator and subordinate CA operator 5
Summarize the results of the discussion and provide decision in the discussion thread and in the Bugzilla Bug Representative of Mozilla 6, 7

(Steps 8-14 are not relevant to intermediate CA 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 15
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 seven days of signing the CA certificate 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: CA Program

● Component: CA Certificate Root Program

● Type: task

● Summary: <your CA's name>: New Subordinate CA Request

Do NOT select the checkboxes 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

  1. May be uploaded as an attachment to the Bugzilla Bug
  2. Subordinate CA audits must follow the same audit rules as for root CAs, as per MRSP section 3
  3. If the subordinate CA is new, a point-in-time audit statement may be initially used
  4. 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:

  1. a large enterprise wants to manage the certificates for domains that they own, or
  2. 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 or the CCADB Public list, the root CA operator must attest that it has verified all 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

Retrieved from "https://wiki.mozilla.org/index.php?title=CA/External_Sub_CAs&oldid=1255052"