Confirmed users
377
edits
CA/Subordinate CA Checklist: Difference between revisions
→Non-disclosable Intermediate Certificates: Added clarification that other root store policies and CCADB may require disclosure.
m (minor cleanup) |
(→Non-disclosable Intermediate Certificates: Added clarification that other root store policies and CCADB may require disclosure.) |
||
| (11 intermediate revisions by 2 users not shown) | |||
| Line 41: | Line 41: | ||
# 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. | # 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 | ||
# Description of audit requirements for sub-CAs (needs to be documented in the CP or CPS) | # 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. | #*Whether or not the root CA audit includes the sub-CAs. | ||
| Line 63: | Line 62: | ||
#* domain ownership/control | #* domain ownership/control | ||
#* email address ownership/control | #* email address ownership/control | ||
# Identify if the SSL certificates chaining up to the sub-CA are DV, OV, and/or EV. | # 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. | #* 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. | #* 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. | |||
# 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 [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#3-documentation Mozilla's Root Store 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.] | ||
| Line 73: | Line 72: | ||
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#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 | 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 server or email certificates. For example, if these subCAs are not used for the production of TLS/SSL or email 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, id-kp-emailProtection, and anyExtendedKeyUsage extensions. (CAVEAT: Public disclosure in the CCADB might still be required by other root store programs. See [https://www.ccadb.org/policy#4-intermediate-certificates Section 4 of the CCADB Policy].) | ||
For example, if these subCAs are not used for the production of TLS/SSL | |||
Alternatively, you can consider restructuring a CA hierarchy such that you have | Alternatively, you can consider restructuring a CA hierarchy such that you have | ||