Confirmed users, Administrators
5,526
edits
CA/Subordinate CA Checklist: Difference between revisions
→Third-Party Public Subordinate CAs
| Line 19: | Line 19: | ||
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. | 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. | ||
== | == 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. | |||
In addition to the information listed above, | 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. | ||
# General description of the sub-CAs operated by third parties. | |||
# 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 | |||
# 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 (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 [http://www.mozilla.org/projects/security/certs/policy/ 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 | |||
# 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. | |||
In addition to the information listed above, the CA must provide the following information for each 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]. | |||
# Sub-CA Company Name | # Sub-CA Company Name | ||
| Line 38: | Line 57: | ||
#* 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 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 | # 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 11, 12, 13, and 14 of [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Mozilla's CA Certificate Inclusion policy.] | ||
# 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. | # 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. | ||
# 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: | # 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: | ||