CA/External Sub CAs: Difference between revisions

Jump to navigation Jump to search

CA/External Sub CAs (view source)

Revision as of 19:16, 8 March 2022

1,048 bytes removed ,  8 March 2022
→‎Summary: Clarifying who the process is applicable to
m (→‎Summary: Added word "unconstrained")
(→‎Summary: Clarifying who the process is applicable to)
Line 5: Line 5:
The operator of a Mozilla-trusted root CA is at all times completely and ultimately accountable for every certificate signed under the root CA, whether directly or through subordinate CAs or cross-certified CAs (subCAs). It is responsible to ensure that each subCA fully and continually complies with requirements.
The operator of a Mozilla-trusted root CA is at all times completely and ultimately accountable for every certificate signed under the root CA, whether directly or through subordinate CAs or cross-certified CAs (subCAs). It is responsible to ensure that each subCA fully and continually complies with requirements.


When a root CA operator intends to sign an unconstrained subCA certificate for use by an external, third-party operator that has not previously undergone this review process for the type of certificate that it will be authorized to issue, the root CA operator is responsible for collecting information and performing due diligence similar to that performed by Mozilla on root inclusion requests (i.e. Quantifying Value and other steps not outlined in this wiki page would not be required), and for '''initiating the public discussion''' on the [https://groups.google.com/a/mozilla.org/g/dev-security-policy Mozilla dev-security-policy mailing list].  
When a root CA operator intends to sign an unconstrained subCA certificate for use by an external, third-party operator that has not previously undergone Mozilla's review process for the type of certificate that it will be authorized to issue, the root CA operator is responsible for collecting information and performing due diligence similar to that performed by Mozilla on root inclusion requests (i.e. Quantifying Value and other steps not outlined in this wiki page would not be required), and for '''initiating the public discussion''' on the [https://groups.google.com/a/mozilla.org/g/dev-security-policy Mozilla dev-security-policy mailing list].  


Following public discussion, the Mozilla CA Program Manager will determine whether the subCA operator will be accepted, and update the corresponding [https://www.ccadb.org/ CCADB] record to indicate the result.
Following public discussion, the Mozilla CA Program Manager will determine whether the subCA operator will be accepted, and update the corresponding [https://www.ccadb.org/ CCADB] record to indicate the result.


The process outlined herein applies to CA operators that either do not already operate a subCA that is trusted by the Mozilla root program, or already operate within the root program, but seek a new subCA certificate that will grant them technical capability to issue kinds of certificates that they previously did not have. Specifically, this process must be followed when an organization does not control a subCA certificate with capability to issue certificates of one or more of the following types and the new subCA certificate will grant such capability: S/MIME (Email trust bit), (DV/IV/OV) TLS Server Authentication (Websites trust bit), and/or EV TLS Server Authentication (Websites trust bit with EV-enablement).
The process outlined herein applies to root CA operators intending to sign a new subCA certificate that will grant the subCA operator the ability to issue certificates that they were not previously capable of issuing. Specifically, this process must be followed when an organization will gain control of a subCA certificate that grants the subCA operator the new ability to issue S/MIME, TLS certificates, or EV TLS certificates. For example, if the prior review/approval of the subCA was only for email certificates, and the subCA operator now wants to issue server certificates, then this process will need to be performed by the root CA operator signing that subCA.


The process outlined herein applies to subCA operators not already in the Mozilla root program, or that have not been previously approved for the type of certificate that they will be capable of issuing. A different procedure would be followed, for instance, when two CA operators already in the Mozilla root program are creating a cross certificate for solely for interoperability or ubiquity. And, if a new or modified CA certificate is to be issued to the same third-party CA operator that has already undergone the full process for the type of end entity certificates being issued, then there is no need to repeat this process (e.g. for renewals or replacements of the subCA certificate). However, if the prior process only reviewed issuance of email certificates, and the CA operator then wants a CA certificate with the serverAuth EKU in order to issue server certificates, then that part of the review process not fully performed must be repeated because of the different requirements and performance expectations. And vice versa, if the CA operator were first approved to issue server certificates and then wanted a CA certificate with the emailProtection EKU to issue email certificates, then any relevant part of the review process that was missed would need to be performed.
The process outlined herein does not apply when new certificate-issuance capabilities are not being introduced, and:
* both CA operators are already in the Mozilla root program; or
* the new subCA certificate is to be issued to a subCA operator who has already undergone this process.


=== Applicable Policy Provisions ===
=== Applicable Policy Provisions ===
Bwilson
Confirmed users
578

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/1241053"

Navigation menu