CA/Subordinate CA Checklist: Difference between revisions

From MozillaWiki
< CA
Jump to navigation Jump to search
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].

Revision as of 21:56, 7 December 2021

Subordinate CA Checklist

In considering a root certificate for inclusion in NSS, Mozilla must also evaluate the current subordinate CAs and the selection/approval criteria for future subordinate CAs. This wiki page outlines subordinate CA information that needs to be provided by the root CA organization, and evaluated by the Mozilla community.

Mozilla’s Root Store Policy encourages CAs to technically constrain subordinate CA certificates using RFC 5280 extensions that are specified directly in the intermediate certificate and controlled by crypto code (e.g. NSS). We recognize that technically constraining subordinate CA certificates in this manner may not be practical in some cases, so the subordinate CA certificates may instead be publicly disclosed, and audited in accordance with Mozilla’s Root Store Policy.

Super-CAs

Some CAs sign the certificates of subordinate CAs to show that they have been accredited or licensed by the signing CA. Such signing CAs are called Super-CAs, and their (first-level) subordinate CAs must apply for inclusion of their own certificates until the following has been established and demonstrated:

  • The Super-CA’s documented policies and audit criteria meet the requirements of Mozilla’s Root Store Policy, which includes the CA/Browser Forum’s Baseline Requirements, and includes sufficient information about verification practices and issuance of end-entity certificates.
  • The Super-CA is at all times completely accountable for their subordinate CAs, and the Super-CA ensures that all subordinate CAs demonstrably adhere to the Super-CA’s documented policies and audit criteria.
  • The Super-CA provides publicly verifiable documentation and proof of annual audits for each subordinate CA that attest to compliance with the Super-CA’s documented policies and audit criteria.
  • The subordinate CAs do not themselves act as a Super-CA or sign a large number of public third-party subordinate CAs, making it difficult for Mozilla and others to annually confirm that the full CA hierarchy is in compliance with Mozilla’s Root Store Policy.

Terminology

The following terminology will be used in this wiki page regarding subordinate CAs.

In-House: The subordinate CA is operated by the same organization operating the root CA.

Third-Party: The subordinate CA is operated by a third party external to the root CA organization; and/or an external third party may directly cause the issuance of a certificate within the CA hierarchy.

Private: The subordinate CA issues certificates only to entities affiliated with the sub-CA organization.

Public: The subordinate CA issues certificates to entities not affiliated with the sub-CA organization.

Root certificate authorities should use a separate and distinct root to sign third-party private subordinate CAs, and such roots should not be submitted for inclusion in NSS. Then if the owner of the subordinate CA later decides to create a profit center and start signing site certificates of unaffiliated entities, those site certificates will not chain back up to a root in NSS. With a separate and distinct root not submitted for inclusion in NSS, there would be no need to disclose any information about those third-party private subordinate CAs.


CA Policies about Third-Party Subordinate CAs

If a CA's policies allow the CA to have subordinate CAs that are operated by third parties, then the following information must be provided.

  1. General description of the sub-CAs operated by third parties.
  2. Selection criteria for sub-CAs
    • The types of organizations that apply to operate a sub-CA
    • The approval process for sub-CAs
    • The verification procedures applied to sub-CAs
  3. The CP/CPS that the sub-CAs are required to follow.
  4. Requirements (technical and contractual) for sub-CAs in regards to whether or not sub-CAs are constrained to issue certificates only within certain domains, and whether or not sub-CAs can create their own subordinates.
  5. Requirements (documented in the CP or CPS) for sub-CAs to take required and reasonable measures to verify the ownership of the domain name and email address for end-entity certificates chaining up to the root.
    • domain ownership/control
    • email address ownership/control
  6. Description of audit requirements for sub-CAs (needs to be documented in the CP or CPS)
    • Whether or not the root CA audit includes the sub-CAs.
    • Who can perform the audits for sub-CAs.
    • Frequency of the audits for sub-CAs.

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 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 Mozilla's Root Store Policy and MUST be publicly disclosed 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.

  1. Sub-CA Company Name
  2. Sub-CA Corporate URL
  3. Sub-CA cert download URL
  4. 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)
  5. General CA hierarchy under the sub-CA.
  6. Sub-CA CP/CPS Links
  7. The section numbers and text (in English) in the CP/CPS that demonstrate that required and reasonable measures are taken to verify the ownership of the domain name and email address for end-entity certificates chaining up to the root.
    • domain ownership/control
    • email address ownership/control
  8. Identify if the SSL 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.
    • 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.
  9. Review the CP/CPS for Potentially Problematic Practices. Provide further info when a potentially problematic practice is found.
  10. 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 Mozilla's Root Store Policy.

Non-disclosable Intermediate Certificates

In order to best ensure the safety and security of Mozilla users, Mozilla has a single consistent 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 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 full public disclosure of their CP, CPS, and audit documentation.

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

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

Retrieved from "https://wiki.allizom.org/index.php?title=CA/Subordinate_CA_Checklist&oldid=1239426"