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.

Version 2.1 of 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.

In the situation where the root CA functions as a super CA such that their CA policies don't apply to the subordinate CAs (including auditing), then the root CA should not be considered for inclusion. Rather, the subordinate CAs may apply for inclusion themselves, as separate trust anchors.

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.

There are four possible combinations:

1. In-house public subordinate CAs: This is the case where a commercial CA establishes one or more internally-operated subordinates to offer certificates of a particular type (e.g., EV vs. non-EV certificates, or SSL certificates vs. email certificates) to the general public.
   • For this case, the standard root inclusion process applies, and it will be verified that the sub-CAs are sufficiently covered by the CP/CPS and audits.
2. In-house private subordinate CAs: This case would cover CA organizations that establish subordinate CAs for internal testing or other internal purposes.
   • For this case, the standard root inclusion process applies, and it will be verified that the sub-CAs are sufficiently covered by the CP/CPS and audits.
3. Third-party public subordinate CAs: In this case the root signs subordinate CAs for organizations who operate the sub-CA to sign certificates for other entities not affiliated with their organization. One example is a commercial CA which establishes one or more subordinate CAs to be operated by third-party organizations acting as Certificate Service Providers (CSP). Another example is a government-sponsored root CA where the organization running the root CA delegates to other organizations the task of issuing end entity certificates to the general public. For example, there might be a separate organization authorized to issue certificates for general business purposes, another organization issuing certificates specifically within a vertical industry sector like financial services, a third organization to issue certificates to individuals, and so on.
   • A typical Mozilla user is likely to encounter certificates issued by these third parties in the course of typical activities like web browsing. Hence we need assurances that these third parties are required to follow practices that satisfy the Mozilla CA Certificate Policy, and we need to ensure that these third parties are under an acceptable audit regime.
   • The root CA is required to disclose the identity of these third parties, because they are essentially functioning as public CAs.
   • Please see the section below which outlines the additional information that must be provided for third-party public subordinate CAs.
4. Third-party private (or enterprise) subordinate CAs: This is the case where a commercial CA has enterprise customers who want to operate their own CAs for internal purposes, e.g., to issue SSL server certificates to systems running intranet applications, to issue individual SSL client certificates for employees or contractors for use in authenticating to such applications, to issue SSL certificates for pre-approved domains that are owned/controlled by the customer, and so on.
   • These sub-CAs are not functioning as public CAs.
   • For these sub-CAs we need assurance that they are not going to start functioning as public CAs. Currently the only assurances available for this case it to ensure that these third parties are required to follow practices that satisfy the Mozilla CA Certificate Policy, and that these third parties are under an acceptable audit regime.
     • In Bug #394919 NSS is being updated to apply dNSName constraints to the CN, in addition to the SANs.
     • We plan to update our policy to require CAs to constrain third-party private (or enterprise) subordinate CAs so they can only issue certificates within a specified domain. See section 4.2.1.10 of RFC 5280.
   • Please see the section below which outlines the additional information that must be provided for third-party private (or enterprise) subordinate CAs.

Recommendation: 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.

Third-Party Private (or Enterprise) Subordinate CAs

When your root signs subordinate CAs for enterprises/companies who operate the sub-CA for their own use, the following information needs to be provided and publicly available.

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 (typically 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 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
6. Description of audit requirements for sub-CAs (typically 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 Public Subordinate CAs

This section applies when your root signs subordinate CAs for companies who use the sub-CA to sign other sub-CAs or certificates for other companies or individuals not affiliated with their company. For instance, this section applies to you if your root issues sub-CAs that are used by Certificate Service Providers (CSP).

In addition to the information listed above, you will also need to provide the following information for each CSP.

1. Sub-CA Company Name
2. Sub-CA Corporate URL
3. Sub-CA cert download URL
4. General CA hierarchy under the sub-CA.
5. Sub-CA CP/CPS Links
6. 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
7. Identify if the SSL certificates chaining up to the sub-CA are DV and/or OV. Some of the potentially problematic practices, only apply to DV certificates.
   • 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.
8. Review the CP/CPS for Potentially Problematic Practices. Provide further info when a potentially problematic practice is found.
9. If the root CA audit does 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 9, 10, and 11 of Mozilla's CA Certificate Inclusion policy.
10. Provide information about the CRL update frequency for end-entity certificates. There should be a statement in the CP/CPS that the sub-CA must follow to the effect that the CRL for end-entity certs is updated whenever a cert is revoked, and at least every 24 or 36 hours.
11. If this sub-CA provides OCSP, then a test must be done to make sure that their OCSP responder works within the Firefox browser. Provide the url to a website whose SSL cert chains up to this sub-CA and has the AIA extension referencing the OCSP responder. The Mozilla representative will perform the following check:
    • Enforce OCSP in Firefox: Tools->Options…->Advanced->Encryption->Validation
    • Select the box for “When an OCSP server connection fails, treat the certificate as invalid”
    • Browse to the given url. Ensure that the website loads without error into Firefox, and that it's SSL cert chains up to the sub-CA and references the OCSP responder in the AIA extension.