CA/Subordinate CA Checklist: Difference between revisions

Jump to navigation Jump to search
m
no edit summary
mNo edit summary
Line 1: Line 1:
In considering a root CA for inclusion, Mozilla must also evaluate the current subordinate CAs as described in this wiki page.
In considering a root CA for inclusion, Mozilla must also evaluate the current subordinate CAs and the selection/approval criteria for future subordinate CAs. This wiki page outlines the information that needs to be provided by the root CA, and evaluated by the Mozilla community.


If Mozilla accepts and includes a root certificate, then we have to assume that we also accept any of that root's future sub-CAs and their sub-CAs. Therefore, the selection criteria for sub-CAs and their sub-CAs is considered a critical decision factor. The CP/CPS should clearly explain the types of organizations that apply to operate a sub-CA (at any level), the selection/approval process for sub-CAs and their sub-CAs, the verification procedures applied to sub-CAs and their sub-CAs, what restrictions (legal and technical) are placed on all sub-CAs (eg constraints to issuing certs within certain domains), and how the sub-CAs are monitored/audited.
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 kind of a super CA and their CA policies don't apply to the subordinate CAs (including auditing), then the root CA should not apply for inclusion. Rather, the subordinate CAs may apply for inclusion themselves, as separate trust anchors.  


== Terminology ==
== Terminology ==
Confirmed users, Administrators
5,526

edits

Navigation menu