CA/External Sub CAs: Difference between revisions

From MozillaWiki
< CA
Jump to navigation Jump to search
m (→‎Summary: Added word "unconstrained")
 
(22 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 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 [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 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 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 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.
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.


=== 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 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. [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#71-inclusions 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.”
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/#8-ca-operational-changes 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.
{| 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)


According to [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. "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 [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited 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."
|-
| 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/#81-change-in-legal-ownership 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."
== Bugzilla Bug ==


=== Process Overview ===
[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.


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].  
● https://bugzilla.mozilla.org/enter_bug.cgi


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


=== Required Documentation ===
● Type: task


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”.
● Summary: &lt;your CA's name&gt;: New Subordinate CA Request


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


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


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 [https://groups.google.com/a/mozilla.org/g/dev-security-policy Mozilla’s dev-security-policy mailing list]:
The following information must be provided by the root CA operator about the potential subordinate CA.


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


3. Expected CA hierarchy under the subCA;
2. Website URL


4. Audit documentation, as explained above;
3. Expected CA hierarchy under the subordinate CA


5. Links to the subCA’s current CP/CPS; and
4. Certificate profile for the subordinate CA certificate


6. The root CA operator must review the subCA operator’s practices, CP/CPS, and completed [[CA/Compliance_Self-Assessment|Compliance Self-Assessment]] for required and prohibited practices.
5. CP, CPS, or CP/CPS for the operation of the subordinate CA


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].
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]]
 
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"