Confirmed users
377
edits
CA/Subordinate CA Checklist: Difference between revisions
→Process for Review and Approval of Externally Operated Subordinate CAs: Edits for re-draft dated 19-Nov-2021
(→Process for Review and Approval of Externally Operated Subordinate CAs: Edits for re-draft dated 19-Nov-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 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 | 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/# | [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 | [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. 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] | 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 | 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 | 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. | 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 | 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. | 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]. | ||