CA/Subordinate CA Checklist - Revision history

Bwilson: /* Non-disclosable Intermediate Certificates */ Removed - outdated

2026-02-02T22:31:04Z

Non-disclosable Intermediate Certificates: Removed - outdated

← Older revision		Revision as of 22:31, 2 February 2026
Line 70:		Line 70:

	Furthermore, for '''externally operated subordinate CAs''', and in accordance with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#84-externally-operated-subordinate-cas MRSP Section 8.4], please refer to '''[[CA/External_Sub_CAs\|this wiki page]]'''.		Furthermore, for '''externally operated subordinate CAs''', and in accordance with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#84-externally-operated-subordinate-cas MRSP Section 8.4], please refer to '''[[CA/External_Sub_CAs\|this wiki page]]'''.

	~~== Non-disclosable Intermediate Certificates ==~~
	In order to best ensure the safety and security of Mozilla users, Mozilla has a single consistent [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy policy] that describes the expectations for all CAs that will be trusted within its program. Mozilla requires that all participating root CAs fully disclose their hierarchy, including CP, CPS, and audits, when said hierarchy is capable of issuance.

	If you have intermediate certificates for which you cannot disclose this information, whether it be for personal, operational, or legal reasons, then an appropriate solution, consistent with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#53-intermediate-certificates Mozilla Root Store Policy], is to use Technically Constrained Subordinate CAs (TCSCAs) - as defined within the CA/Browser Forum's Baseline Requirements and as reflected within Mozilla's policy. Such TCSCAs are technically limited from the issuance of TLS server or email certificates. For example, if these subCAs are not used for the production of TLS/SSL or email certificates, then you can make use of the Extended Key Usage extension on the sub-CA to ensure it is present, and that it lacks the id-kp-serverAuth, id-kp-emailProtection, and anyExtendedKeyUsage extensions. (CAVEAT: Public disclosure in the CCADB might still be required by other root store programs. See [https://www.ccadb.org/policy#4-intermediate-certificates Section 4 of the CCADB Policy].)

	~~Alternatively, you can consider restructuring a CA hierarchy such that you have~~

	~~:::/-Private Sub CA 1~~
	~~::/--Private Sub CA 2~~
	~~:Root~~
	~~::\~~
	~~:::\-BR-compliant Public Intermediate {This is the cert you would request Mozilla include as a Trust Anchor.}~~
	~~::::\~~
	~~:::::\----BR-compliant SubCA1~~
	~~::::::\---BR-compliant SubCA2~~
	~~:::::::\--BR-compliant SubCA3~~

	That is, in this structure, an additional intermediate is inserted into your PKI which distinguishes the "private" (confidential) sub-CAs, and the publicly audited, publicly disclosed set of sub-CAs. In this scenario, rather than all chaining directly to the Root, they transit a newly introduced intermediate. It is this newly introduced intermediate that you would 'apply' for inclusion to Mozilla as the root, even if operationally, your government might use and rely on "Root" for the broader purpose of digital signature identification or operational management.

	The point of this is that Mozilla Policy requires that all nodes signed by the trust anchor (using the RFC5280 terminology, since it doesn't need to be a self-signed cert), whether it's 'root' or 'BR-compliant Public Intermediate', MUST be operated and disclosed in a way consistent with Mozilla Policy. If you have a 'private' PKI (even if it's publicly operated for the benefit of citizens and/or customers), then it MUST be a sibling-or-parent node in the PKI tree, and MUST NOT be a child node.

Bwilson: /* Third-Party Subordinate CAs that are not Technically Constrained */ Clarified requirements and update page

2026-01-31T14:19:57Z

Third-Party Subordinate CAs that are not Technically Constrained: Clarified requirements and update page

← Older revision		Revision as of 14:19, 31 January 2026
Line 49:		Line 49:
	== Third-Party Subordinate CAs that are not Technically Constrained ==		== Third-Party Subordinate CAs that are not Technically Constrained ==

	All certificates that are capable of being used to issue new certificates, that are not technically constrained as described in section 5.3 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#53-intermediate-certificates Mozilla's Root Store Policy], and that directly or transitively chain to a certificate included in Mozilla's CA Certificate Program MUST be audited in accordance with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#3-documentation Mozilla's Root Store Policy] and MUST be publicly disclosed by the CA that has their certificate included in Mozilla's CA Certificate Program.		All certificates that are capable of being used to issue new certificates, that are not technically constrained as described in section 5.3 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#53-intermediate-certificates Mozilla's Root Store Policy], and that directly or transitively chain to a certificate included in Mozilla's CA Certificate Program MUST be audited in accordance with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#3-documentation Mozilla's Root Store Policy] and MUST be publicly disclosed '''in the CCADB''' by the CA that has their certificate included in Mozilla's CA Certificate Program.

	~~In addition to the~~ information ~~listed above, the CA~~ must ~~provide~~ the ~~following information~~ for each third-party subordinate CA certificate that is not technically constrained.		The following information must be provided '''in the CCDAB''' for each third-party subordinate CA certificate that is not technically constrained.

	# Sub-CA Company Name		# Sub-CA Company Name
	# Sub-CA Corporate URL		# Sub-CA Corporate URL
	# Sub-CA cert download URL		# Sub-CA cert download URL
	# URL to a test website whose ~~SSL~~ certificate chains up to this Sub-CA's certificate (if this Sub-CA is allowed to issue ~~SSL~~ certificates)		# URL to a test website whose TLS certificate chains up to this Sub-CA's certificate (if this Sub-CA is allowed to issue TLS certificates)
	# General CA hierarchy under the sub-CA.		# General CA hierarchy under the sub-CA.
	# Sub-CA CP/CPS Links		# Sub-CA CP/CPS Links
Line 62:		Line 62:
	#* domain ownership/control		#* domain ownership/control
	#* email address ownership/control		#* email address ownership/control
	# Identify if the ~~SSL~~ certificates chaining up to the sub-CA are DV, OV, and/or EV.		# Identify if the TLS certificates chaining up to the sub-CA are DV, OV, and/or EV.
	#* DV: Organization attribute is not verified. Only the Domain Name referenced in the certificate is verified to be owned/controlled by the subscriber.		#* DV: Organization attribute is not verified. Only the Domain Name referenced in the certificate is verified to be owned/controlled by the subscriber.
	#* OV: Both the Organization and the ownership/control of the Domain Name are verified.		#* OV: Both the Organization and the ownership/control of the Domain Name are verified.
Line 68:		Line 68:
	# Review the CP/CPS for [http://wiki.mozilla.org/CA:Problematic_Practices Potentially Problematic Practices.] Provide further info when a potentially problematic practice is found.		# Review the CP/CPS for [http://wiki.mozilla.org/CA:Problematic_Practices Potentially Problematic Practices.] Provide further info when a potentially problematic practice is found.
	# If the root CA audits do not include this sub-CA, then for this sub-CA provide a publishable statement or letter from an auditor that meets the requirements of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#3-documentation Mozilla's Root Store Policy.]		# If the root CA audits do not include this sub-CA, then for this sub-CA provide a publishable statement or letter from an auditor that meets the requirements of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#3-documentation Mozilla's Root Store Policy.]

			Furthermore, for '''externally operated subordinate CAs''', and in accordance with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#84-externally-operated-subordinate-cas MRSP Section 8.4], please refer to '''[[CA/External_Sub_CAs\|this wiki page]]'''.

	== Non-disclosable Intermediate Certificates ==		== Non-disclosable Intermediate Certificates ==

Bwilson: /* Non-disclosable Intermediate Certificates */ Added clarification that other root store policies and CCADB may require disclosure.

2022-10-21T04:51:04Z

Non-disclosable Intermediate Certificates: Added clarification that other root store policies and CCADB may require disclosure.

← Older revision		Revision as of 04:51, 21 October 2022
Line 72:		Line 72:
	In order to best ensure the safety and security of Mozilla users, Mozilla has a single consistent [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy policy] that describes the expectations for all CAs that will be trusted within its program. Mozilla requires that all participating root CAs fully disclose their hierarchy, including CP, CPS, and audits, when said hierarchy is capable of issuance.		In order to best ensure the safety and security of Mozilla users, Mozilla has a single consistent [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy policy] that describes the expectations for all CAs that will be trusted within its program. Mozilla requires that all participating root CAs fully disclose their hierarchy, including CP, CPS, and audits, when said hierarchy is capable of issuance.

	If you have intermediate certificates for which you cannot disclose this information, whether it be for personal, operational, or legal reasons, then an appropriate solution, consistent with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#53-intermediate-certificates Mozilla Root Store Policy], is to use Technically Constrained Subordinate CAs (TCSCAs) - as defined within the CA/Browser Forum's Baseline Requirements and as reflected within Mozilla's policy. Such TCSCAs are technically limited from the issuance of TLS~~/SSL~~ certificates~~, and by doing so, are allowed to be operated without [https://www.ccadb~~.~~org/cas/intermediates full public disclosure of their CP, CPS, and audit documentation].~~		If you have intermediate certificates for which you cannot disclose this information, whether it be for personal, operational, or legal reasons, then an appropriate solution, consistent with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#53-intermediate-certificates Mozilla Root Store Policy], is to use Technically Constrained Subordinate CAs (TCSCAs) - as defined within the CA/Browser Forum's Baseline Requirements and as reflected within Mozilla's policy. Such TCSCAs are technically limited from the issuance of TLS server or email certificates. For example, if these subCAs are not used for the production of TLS/SSL or email certificates, then you can make use of the Extended Key Usage extension on the sub-CA to ensure it is present, and that it lacks the id-kp-serverAuth, id-kp-emailProtection, and anyExtendedKeyUsage extensions. (CAVEAT: Public disclosure in the CCADB might still be required by other root store programs. See [https://www.ccadb.org/policy#4-intermediate-certificates Section 4 of the CCADB Policy].)

	For example, if these subCAs are not used for the production of TLS/SSL ~~certificates, but only identity~~ certificates, then you can make use of the Extended Key Usage extension on the sub-CA to ensure it is present, and that it lacks the id-kp-serverAuth and anyExtendedKeyUsage extensions.

	Alternatively, you can consider restructuring a CA hierarchy such that you have		Alternatively, you can consider restructuring a CA hierarchy such that you have

Bwilson: /* Process for Review and Approval of Externally Operated Subordinate CAs */ Removed section

2021-12-07T21:56:05Z

Process for Review and Approval of Externally Operated Subordinate CAs: Removed section

← Older revision		Revision as of 21:56, 7 December 2021
Line 91:		Line 91:

	The point of this is that Mozilla Policy requires that all nodes signed by the trust anchor (using the RFC5280 terminology, since it doesn't need to be a self-signed cert), whether it's 'root' or 'BR-compliant Public Intermediate', MUST be operated and disclosed in a way consistent with Mozilla Policy. If you have a 'private' PKI (even if it's publicly operated for the benefit of citizens and/or customers), then it MUST be a sibling-or-parent node in the PKI tree, and MUST NOT be a child node.		The point of this is that Mozilla Policy requires that all nodes signed by the trust anchor (using the RFC5280 terminology, since it doesn't need to be a self-signed cert), whether it's 'root' or 'BR-compliant Public Intermediate', MUST be operated and disclosed in a way consistent with Mozilla Policy. If you have a 'private' PKI (even if it's publicly operated for the benefit of citizens and/or customers), then it MUST be a sibling-or-parent node in the PKI tree, and MUST NOT be a child node.

	~~== Process for Review and Approval of Externally Operated Subordinate CAs ==~~

	~~'''DRAFT of 19-Nov-2021'''~~

	~~=== Summary ===~~

	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 (see above), 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].

	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.

	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 ===~~

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

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

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

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

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

	The public discussion phase should also 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 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 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 [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.~~

	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 [https://groups.google.com/a/mozilla.org/g/dev-security-policy 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 [[CA/Compliance_Self-Assessment\|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 [https://crt.sh/mozilla-onecrl OneCRL].

Bwilson: /* Process for Review and Approval of Externally Operated Subordinate CAs */ Edits for re-draft dated 19-Nov-2021

2021-11-19T23:02:45Z

Process for Review and Approval of Externally Operated Subordinate CAs: Edits for re-draft dated 19-Nov-2021

Bwilson: /* DRAFT: Process for Considering Externally Operated Subordinate CAs */ Finalized

2021-10-28T20:43:39Z

DRAFT: Process for Considering Externally Operated Subordinate CAs: Finalized

← Older revision		Revision as of 20:43, 28 October 2021
Line 92:		Line 92:
	The point of this is that Mozilla Policy requires that all nodes signed by the trust anchor (using the RFC5280 terminology, since it doesn't need to be a self-signed cert), whether it's 'root' or 'BR-compliant Public Intermediate', MUST be operated and disclosed in a way consistent with Mozilla Policy. If you have a 'private' PKI (even if it's publicly operated for the benefit of citizens and/or customers), then it MUST be a sibling-or-parent node in the PKI tree, and MUST NOT be a child node.		The point of this is that Mozilla Policy requires that all nodes signed by the trust anchor (using the RFC5280 terminology, since it doesn't need to be a self-signed cert), whether it's 'root' or 'BR-compliant Public Intermediate', MUST be operated and disclosed in a way consistent with Mozilla Policy. If you have a 'private' PKI (even if it's publicly operated for the benefit of citizens and/or customers), then it MUST be a sibling-or-parent node in the PKI tree, and MUST NOT be a child node.

	== ~~DRAFT:~~ Process for ~~Considering~~ Externally Operated Subordinate CAs ==		== Process for Review and Approval of Externally Operated Subordinate CAs ==

	=== Summary ===		=== Summary ===
Line 98:		Line 98:
	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. It is responsible to ensure that the subCA fully and continually complies with requirements.		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. It is responsible to ensure that the subCA fully and continually complies with requirements.

	When a root CA intends to sign an externally operated subordinate CA (subCA) certificate, it is responsible for collecting information and performing due diligence that meets or exceeds that performed by Mozilla on root inclusion requests, 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 ~~or not~~ the subordinate CA will be accepted, and update the corresponding CCADB record to indicate the result.		When a root CA intends to sign an externally operated subordinate CA (subCA) certificate, it is responsible for collecting information and performing due diligence that meets or exceeds that performed by Mozilla on root inclusion requests, 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]. Following public discussion, the Mozilla CA Program Manager will determine whether the subordinate CA will be accepted, and update the corresponding [https://www.ccadb.org/ CCADB] record to indicate the result.

	The process outlined herein applies to subCA operators not already in the Mozilla root program. A different procedure would be followed, for instance, when two CA operators already in the Mozilla root program are creating a cross certificate for interoperability or ubiquity.		The process outlined herein applies to subCA operators not already in the Mozilla root program. A different procedure would be followed, for instance, when two CA operators already in the Mozilla root program are creating a cross certificate for interoperability or ubiquity.
Line 104:		Line 104:
	=== Applicable Policy Provisions ===		=== Applicable Policy Provisions ===

	Section 8 of the Mozilla Root Store Policy (MRSP) requires that root CA operators notify Mozilla when a new third party is going to operate a trusted CA outside of the confines of the CA operator’s existing operations.		[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#8-ca-operational-changes Section 8] of the Mozilla Root Store Policy (MRSP) requires that root CA operators notify Mozilla when a new third party is going to operate a trusted CA outside of the confines of the CA operator’s existing operations.

	According to ~~Section~~ 8 of the Mozilla ~~Root Store Policy~~,		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."

	~~CAs SHOULD NOT 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.~~		[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#81-change-in-legal-ownership MRSP § 8.1] states, "If the receiving or acquiring company is new to the Mozilla root program, it 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."

	~~Mozilla Root Store Policy section~~ 8.1 states:

	If the receiving or acquiring company is new to the Mozilla root program, it 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 ===		=== Process Overview ===
Line 122:		Line 118:
	In either case, Mozilla’s prior approval is required because discussion must be “resolved with a positive conclusion” before issuance of end entity certificates.		In either case, Mozilla’s prior approval is required because discussion must be “resolved with a positive conclusion” before issuance of end entity certificates.

	In any event, public disclosure of the subCA in the CCADB must occur within one week as required by MRSP § 5.3.2. Part of the disclosure involves indicating whether the subCA is covered by the same audits as the parent CA or whether it has a separate audit.		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]. Part of the disclosure involves indicating whether the subCA is covered by the same audits as the parent CA or whether it has a separate audit.

	=== Required Documentation ===		=== 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”.		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 submit an auditor’s key generation report for the key pair that is signed by the root CA. It is also the root CA operator’s obligation to provide audit statements for the subCA. The key generation report and relevant audit statement(s) should be uploaded to the bug in Bugzilla and referenced in the subCA’s record in the CCADB.		The root CA operator must submit an auditor’s key generation report for the key pair that is signed by the root CA. It is also the root CA operator’s obligation to provide audit statements for the subCA. The key generation report and relevant audit statement(s) should be uploaded to the bug in Bugzilla and referenced in the subCA’s record in the CCADB.
Line 132:		Line 128:
	SubCA audits MUST follow the same audit rules as for root CAs. If the subCA is new, it need only supply a type-1 (point-in-time) audit statement to Mozilla prior to approval. The new subCA certificate must appear in subsequent type-2 (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. For more information, see Mozilla’s Policy about Third-Party Subordinate CAs.		SubCA audits MUST follow the same audit rules as for root CAs. If the subCA is new, it need only supply a type-1 (point-in-time) audit statement to Mozilla prior to approval. The new subCA certificate must appear in subsequent type-2 (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. For more information, see Mozilla’s Policy about Third-Party Subordinate CAs.

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

	1. External Third Party’s Full Legal Name		1. External Third Party’s Full Legal Name
Line 140:		Line 136:
	3. Expected CA hierarchy under the subCA		3. Expected CA hierarchy under the subCA

	4. Audits - If the root CA audits do not include the SHA256 hash for this subCA, then provide a publishable statement or letter from an auditor that meets the requirements of ~~Mozilla's Root Store Policy~~.		4. Audits - If the root CA's audits do not include the SHA256 hash for this subCA, then provide a publishable statement or letter from an auditor that meets the requirements of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#31-audits MRSP § 3.1].

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

	6. The CA must review the subCA’s CP/CPS for required and prohibited practices.		6. The root CA operator must review the subCA’s practices, CP/CPS, and completed [[CA/Compliance_Self-Assessment\|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. If the subCA 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.		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. If the subCA 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].

Bwilson: /* Required Documentation */ Changed formatting and "should

2021-09-27T18:47:04Z

Required Documentation: Changed formatting and "should

← Older revision		Revision as of 18:47, 27 September 2021
Line 130:		Line 130:
	The root CA operator must submit an auditor’s key generation report for the key pair that is signed by the root CA. It is also the root CA operator’s obligation to provide audit statements for the subCA. The key generation report and relevant audit statement(s) should be uploaded to the bug in Bugzilla and referenced in the subCA’s record in the CCADB.		The root CA operator must submit an auditor’s key generation report for the key pair that is signed by the root CA. It is also the root CA operator’s obligation to provide audit statements for the subCA. The key generation report and relevant audit statement(s) should be uploaded to the bug in Bugzilla and referenced in the subCA’s record in the CCADB.

	SubCA audits ~~should~~ follow the same audit rules as for root CAs. If the subCA is new, it need only supply a type-1 (point-in-time) audit statement to Mozilla prior to approval. The new subCA certificate must appear in subsequent type-2 (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. For more information, see Mozilla’s Policy about Third-Party Subordinate CAs.		SubCA audits MUST follow the same audit rules as for root CAs. If the subCA is new, it need only supply a type-1 (point-in-time) audit statement to Mozilla prior to approval. The new subCA certificate must appear in subsequent type-2 (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. For more information, see Mozilla’s Policy about Third-Party Subordinate CAs.

	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.		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		1. External Third Party’s Full Legal Name

	2. External Third Party’s Website URL		2. External Third Party’s Website URL

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

	4. Audits - If the root CA audits do not include the SHA256 hash for this subCA, then provide a publishable statement or letter from an auditor that meets the requirements of Mozilla's Root Store Policy.		4. Audits - If the root CA audits do not include the SHA256 hash for this subCA, then provide a publishable statement or letter from an auditor that meets the requirements of Mozilla's Root Store Policy.

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

	6. The CA must review the subCA’s CP/CPS for required and prohibited practices.		6. The CA must review the subCA’s CP/CPS 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. If the subCA 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.		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. If the subCA 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.

Bwilson: Added draft Process for Considering Externally Operated Subordinate CAs

2021-09-26T17:18:35Z

Added draft Process for Considering Externally Operated Subordinate CAs

← Older revision		Revision as of 17:18, 26 September 2021
Line 91:		Line 91:

	The point of this is that Mozilla Policy requires that all nodes signed by the trust anchor (using the RFC5280 terminology, since it doesn't need to be a self-signed cert), whether it's 'root' or 'BR-compliant Public Intermediate', MUST be operated and disclosed in a way consistent with Mozilla Policy. If you have a 'private' PKI (even if it's publicly operated for the benefit of citizens and/or customers), then it MUST be a sibling-or-parent node in the PKI tree, and MUST NOT be a child node.		The point of this is that Mozilla Policy requires that all nodes signed by the trust anchor (using the RFC5280 terminology, since it doesn't need to be a self-signed cert), whether it's 'root' or 'BR-compliant Public Intermediate', MUST be operated and disclosed in a way consistent with Mozilla Policy. If you have a 'private' PKI (even if it's publicly operated for the benefit of citizens and/or customers), then it MUST be a sibling-or-parent node in the PKI tree, and MUST NOT be a child node.

			== DRAFT: Process for Considering Externally Operated Subordinate CAs ==

			=== Summary ===

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

			When a root CA intends to sign an externally operated subordinate CA (subCA) certificate, it is responsible for collecting information and performing due diligence that meets or exceeds that performed by Mozilla on root inclusion requests, 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 or not the subordinate CA will be accepted, and update the corresponding CCADB record to indicate the result.

			The process outlined herein applies to subCA operators not already in the Mozilla root program. A different procedure would be followed, for instance, when two CA operators already in the Mozilla root program are creating a cross certificate for interoperability or ubiquity.

			=== Applicable Policy Provisions ===

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

			According to Section 8 of the Mozilla Root Store Policy,

			CAs SHOULD NOT 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.

			Mozilla Root Store Policy section 8.1 states:

			If the receiving or acquiring company is new to the Mozilla root program, it 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 set forth in the numbered list below.

			The public discussion phase should also occur prior to the signing of the subCA. However, current policy permits public discussion to occur following signing.

			In either case, Mozilla’s prior approval is required because discussion must be “resolved with a positive conclusion” before issuance of end entity certificates.

			In any event, public disclosure of the subCA in the CCADB must occur within one week as required by MRSP § 5.3.2. Part of the disclosure involves indicating whether the subCA is covered by the same audits as the parent CA or whether it has a separate audit.

			=== 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 submit an auditor’s key generation report for the key pair that is signed by the root CA. It is also the root CA operator’s obligation to provide audit statements for the subCA. The key generation report and relevant audit statement(s) should be uploaded to the bug in Bugzilla and referenced in the subCA’s record in the CCADB.

			SubCA audits should follow the same audit rules as for root CAs. If the subCA is new, it need only supply a type-1 (point-in-time) audit statement to Mozilla prior to approval. The new subCA certificate must appear in subsequent type-2 (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. For more information, see Mozilla’s Policy about Third-Party Subordinate CAs.

			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. Audits - If the root CA audits do not include the SHA256 hash for this subCA, then provide a publishable statement or letter from an auditor that meets the requirements of Mozilla's Root Store Policy.
			5. Links to the subCA’s current CP/CPS
			6. The CA must review the subCA’s CP/CPS 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. If the subCA 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.

Kathleen Wilson: Protected "CA/Subordinate CA Checklist" ([Edit=Allow confirmed users only] (indefinite) [Move=Allow confirmed users only] (indefinite))

2021-08-25T00:00:07Z

Protected "CA/Subordinate CA Checklist" ([Edit=Allow confirmed users only] (indefinite) [Move=Allow confirmed users only] (indefinite))

← Older revision	Revision as of 00:00, 25 August 2021
(No difference)

Bwilson: /* Third-Party Subordinate CAs that are not Technically Constrained */ Added bullet item for EV

2021-05-11T16:03:35Z

Third-Party Subordinate CAs that are not Technically Constrained: Added bullet item for EV

← Older revision		Revision as of 16:03, 11 May 2021
Line 65:		Line 65:
	#* DV: Organization attribute is not verified. Only the Domain Name referenced in the certificate is verified to be owned/controlled by the subscriber.		#* DV: Organization attribute is not verified. Only the Domain Name referenced in the certificate is verified to be owned/controlled by the subscriber.
	#* OV: Both the Organization and the ownership/control of the Domain Name are verified.		#* OV: Both the Organization and the ownership/control of the Domain Name are verified.
			#* EV: Extended validation was performed on the legal entity and its operational existence.
	# Review the CP/CPS for [http://wiki.mozilla.org/CA:Problematic_Practices Potentially Problematic Practices.] Provide further info when a potentially problematic practice is found.		# Review the CP/CPS for [http://wiki.mozilla.org/CA:Problematic_Practices Potentially Problematic Practices.] Provide further info when a potentially problematic practice is found.
	# If the root CA audits do not include this sub-CA, then for this sub-CA provide a publishable statement or letter from an auditor that meets the requirements of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#3-documentation Mozilla's Root Store Policy.]		# If the root CA audits do not include this sub-CA, then for this sub-CA provide a publishable statement or letter from an auditor that meets the requirements of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#3-documentation Mozilla's Root Store Policy.]

← Older revision		Revision as of 23:02, 19 November 2021
Line 93:		Line 93:

	== Process for Review and Approval of Externally Operated Subordinate CAs ==		== Process for Review and Approval of Externally Operated Subordinate CAs ==

			'''DRAFT of 19-Nov-2021'''

	=== Summary ===		=== Summary ===

	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. It is responsible to ensure that ~~the~~ subCA fully and continually complies with requirements.		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 intends to sign an ~~externally operated subordinate CA~~ (~~subCA~~) ~~certificate~~, it is responsible for collecting information and performing due diligence ~~that meets or exceeds~~ that performed by Mozilla on root inclusion requests, 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]. Following public discussion, the Mozilla CA Program Manager will determine whether the subordinate CA will be accepted, and update the corresponding [https://www.ccadb.org/ CCADB] record to indicate the result.		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 (see above), 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 subCA operators not already in the Mozilla root program. A different procedure would be followed, for instance, when two CA operators already in the Mozilla root program are creating a cross certificate for interoperability or ubiquity.		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.

			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 ===		=== Applicable Policy Provisions ===

	[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#~~8-ca~~-~~operational~~-~~changes~~ Section 8] of the Mozilla Root Store Policy (MRSP) requires that root CA operators notify Mozilla when a new third party is going to operate a trusted CA outside of the confines of the CA operator’s existing operations.		[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.”

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

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

	[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#81-change-in-legal-ownership MRSP § 8.1] states~~, "If~~ the receiving or acquiring company ~~is new to the Mozilla root program, it~~ 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."		[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."

	=== Process Overview ===		=== 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 set forth in the numbered list below.		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.

	~~The public discussion phase should also occur prior to the signing of the subCA. However, current policy permits public discussion to occur following signing~~.

	~~In either case~~, ~~Mozilla’s prior approval is required because~~ discussion ~~must be “resolved with~~ a ~~positive conclusion” before issuance~~ of ~~end entity certificates~~.		The public discussion phase should also 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 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]~~. Part~~ of ~~the disclosure involves indicating~~ whether the subCA is covered by the same audits as the parent CA or whether it has a separate audit.		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.

	=== Required Documentation ===		=== Required Documentation ===
Line 124:		Line 130:
	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”.		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 ~~submit an auditor’s key generation report for the key pair that is signed by the root CA. It is also the root CA operator’s obligation to~~ provide audit statements for the subCA~~. The key generation report and relevant audit statement(s)~~ should be uploaded to the bug in Bugzilla and referenced in the subCA’s record in the CCADB.		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, it need only supply a ~~type-1 (~~point-in-time) audit statement to Mozilla prior to approval. The new subCA certificate must appear in subsequent ~~type-2 (~~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~~. For more information, see Mozilla’s Policy about Third-Party Subordinate CAs~~.		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 [https://groups.google.com/a/mozilla.org/g/dev-security-policy Mozilla’s dev-security-policy mailing list].		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]:

	1. External Third Party’s Full Legal Name		1. External Third Party’s Full Legal Name;

	2. External Third Party’s Website URL		2. External Third Party’s Website URL;

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

	4. ~~Audits - If the root CA's audits do not include the SHA256 hash for this subCA~~, then provide a publishable statement or letter from an auditor that meets the requirements of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#31-audits MRSP § 3.1].		4. Audit documentation, as explained above;

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

	6. The root CA operator must review the ~~subCA’s~~ practices, CP/CPS, and completed [[CA/Compliance_Self-Assessment\|Compliance Self-Assessment]] for required and prohibited practices.		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.

	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. If the subCA 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].		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].