Confirmed users, Administrators
5,526
edits
mNo edit summary |
|||
Line 1: | Line 1: | ||
= 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 | 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 [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. | |||
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. | 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. |