CA/Subordinate CA Checklist

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 CA Certificate Policy (sections 8, 9, and 10) 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 CA Certificate 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 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 CA Certificate 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 CA Certificate 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.
   • Sections 8 through 10 of Mozilla's CA Certificate Inclusion Policy
   • Sections 9.7 and 17 of the CA/Browser Forum's Baseline Requirements
5. Requirements (documented in the CP or CPS) for sub-CAs to take reasonable measures to verify the ownership of the domain name and email address for end-entity certificates chaining up to the root, as per section 7 of Mozilla's CA Certificate Inclusion Policy
   • domain ownership/control
   • email address ownership/control
   • digitally signing code objects -- entity submitting the certificate signing request is the same entity referenced in the certificate
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 item #9 of Mozilla's CA Certificate Inclusion 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 CA Certificate 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 as described in item #9 of Mozilla's CA Certificate Inclusion Policy.

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 reasonable measures are taken to verify the ownership of the domain name and email address for end-entity certificates chaining up to the root, as per section 7 of our Mozilla CA certificate policy.
   • domain ownership/control
   • email address ownership/control
   • digitally signing code objects -- entity submitting the certificate signing request is the same entity referenced in the certificate
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.
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 sections 11, 12, 13, and 14 of Mozilla's CA Certificate Inclusion policy.