CA/Subordinate CA Checklist: Difference between revisions

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.
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 kind of a super CA and their CA policies don't apply to the subordinate CAs (including auditing), then the subordinate CAs must apply for inclusion themselves, as separate trust anchors.
== Terminology ==
== Terminology ==
The following terminology will be used in this wiki page regarding subordinate CAs.
The following terminology will be used in this wiki page regarding subordinate CAs.
Confirmed users, Administrators
5,526

edits