CA/Subordinate CA Checklist: Difference between revisions

Updated references and links to Mozilla's root store policy
(Updated references and links to Mozilla's root store policy)
Line 2: Line 2:
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.
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.


[http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html 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.
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#53-intermediate-certificates 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 CA Certificate Policy.


== Super-CAs ==
== 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:
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 [http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla’s CA Certificate Policy], which includes the [https://cabforum.org/baseline-requirements/ CA/Browser Forum’s Baseline Requirements], and includes sufficient information about verification practices and issuance of end-entity certificates.
* The Super-CA’s documented policies and audit criteria meet the requirements of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#3-documentation Mozilla’s Root Store Policy], which includes the [https://cabforum.org/baseline-requirements/ 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 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 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 [[CA:SubordinateCA_checklist#Terminology | public third-party subordinate CAs]], making it difficult for Mozilla and others to annually confirm that the full CA hierarchy is in compliance with [http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla’s CA Certificate Policy].
* The subordinate CAs do not themselves act as a Super-CA or sign a large number of [[CA:SubordinateCA_checklist#Terminology | public third-party subordinate CAs]], making it difficult for Mozilla and others to annually confirm that the full CA hierarchy is in compliance with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla’s Root Store Policy].


== Terminology ==
== Terminology ==
Line 37: Line 37:
# The CP/CPS that the sub-CAs are required to follow.
# The CP/CPS that the sub-CAs are required to follow.
# 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.
# 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 [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy]
#* Section 5.3 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#53-intermediate-certificates Mozilla's Root Store Policy]
#* Sections 9.7 and 17 of the CA/Browser Forum's [https://cabforum.org/baseline-requirements-documents/ Baseline Requirements]
#* The CA/Browser Forum's [https://cabforum.org/baseline-requirements-documents/ Baseline Requirements]
# 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 [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy]
# 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
#* domain ownership/control
#* email address ownership/control  
#* email address ownership/control  
Line 50: Line 50:
== Third-Party Subordinate CAs that are not Technically Constrained ==
== 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 [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html 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 [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Mozilla's CA Certificate Policy] and MUST be publicly disclosed by the CA that has their certificate included in Mozilla's CA Certificate Program.  
All certificates that are capable of being used to issue new certificates, that are not technically constrained as described in section 5.3 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#53-intermediate-certificates 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 [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#3-documentation 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 as described in item #9 of [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Mozilla's CA Certificate Inclusion Policy].
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.


# Sub-CA Company Name
# Sub-CA Company Name
Line 60: Line 60:
# General CA hierarchy under the sub-CA.
# General CA hierarchy under the sub-CA.
# Sub-CA CP/CPS Links
# Sub-CA CP/CPS Links
# 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 [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA certificate policy].
# 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
#* domain ownership/control
#* email address ownership/control  
#* email address ownership/control  
Line 68: Line 68:
#* OV: Both the Organization and the ownership/control of the Domain Name are verified.  
#* OV: Both the Organization and the ownership/control of the Domain Name are verified.  
# Review the CP/CPS for [http://wiki.mozilla.org/CA:Problematic_Practices Potentially Problematic Practices.] Provide further info when a potentially problematic practice is found.
# Review the CP/CPS for [http://wiki.mozilla.org/CA:Problematic_Practices Potentially Problematic Practices.] Provide further info when a potentially problematic practice is found.
# 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 [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Mozilla's CA Certificate Inclusion policy.]
# 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 [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#3-documentation Mozilla's Root Store Policy.]


== Non-disclosable Intermediate Certificates ==
== Non-disclosable Intermediate Certificates ==
In order to best ensure the safety and security of Mozilla users, Mozilla has a single consistent [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ 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.
In order to best ensure the safety and security of Mozilla users, Mozilla has a single consistent [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy 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 [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla CA Certificate Policy], is to use Technically Constrained Subordinate CAs (TCSCAs) - as defined within the [[CA:BaselineRequirements|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 [[CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F|public disclosure of their CP, CPS, and audit documentation]].
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 [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#53-intermediate-certificates 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 [[CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F|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.
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.
Confirmed users, Administrators
5,526

edits