Confirmed users
377
edits
CA/Subordinate CA Checklist: Difference between revisions
→DRAFT: Process for Considering Externally Operated Subordinate CAs: Finalized
m (→Required Documentation: Changed formatting and "should) |
|||
| 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. | ||
== | == 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 | 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 | 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." | |||
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 | 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]. | ||