CA/Forbidden or Problematic Practices: Difference between revisions

Jump to navigation Jump to search
Update "Allowing External Entities to Operate Subordinate CAs" with new wording by Kathleen
(General cleanup)
(Update "Allowing External Entities to Operate Subordinate CAs" with new wording by Kathleen)
Line 31: Line 31:
== Allowing External Entities to Operate Subordinate CAs ==
== Allowing External Entities to Operate Subordinate CAs ==


Some CAs authorize external entities to operate their own CAs as subordinate CAs under the original CA's root. This raises concerns relating to whether or not such external entities are audited in a manner equivalent to the root CA, as well as what legal and technical arrangements constrain the external entities.
Some CAs authorize external entities to operate their own CAs as subordinate CAs under the original CA's root. 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. If Mozilla accepts and includes a CA's root certificate, then we have to assume that we also accept any of their future sub-CAs and their sub-CAs. Therefore, the selection criteria for a CA's sub-CAs and their sub-CAs will be a critical decision factor, as well as the documentation and auditing-of-operations requirements that the CA places on such relationships.


Where a root from a CA signs an intermediate certificate used by an external CA to then sign subsidiary intermediate certificates or subscriber certificates, that situation needs to be disclosed. That disclosure should include documentation of what requirements are imposed by the CA owning the root upon the operations of external CAs.  Further, the public audit report for the CA owning the root must indicate how and when the operations of the external CAs have been reviewed for compliance with those documented requirements.
In order to best ensure the safety and security of Mozilla users, Mozilla has a [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ single consistent policy] that describes the expectations for all CAs that will be trusted within its program. Mozilla requires that all participating root CAs fully disclose their hierarchy, including CP, CPS, and audits, when said hierarchy is capable of SSL or email issuance.


You must provide a clear description of the subordinate CAs that are operated by external third parties, and an explanation as to how the CP/CPS and audits ensure the third parties are in compliance with Mozilla's CA Certificate Policy requirements as per the [https://wiki.mozilla.org/CA:SubordinateCA_checklist Subordinate CA Checklist.]
More information on our disclosure requirements [https://wiki.mozilla.org/CA:SubordinateCA_checklist#Non-disclosable_Intermediate_Certificates is available].
 
During the root inclusion/change process, CAs must provide a clear description of the subordinate CAs that are operated by external third parties, and an explanation as to how the CP/CPS and audits ensure the third parties are in compliance with Mozilla's CA Certificate Policy requirements as per the Subordinate CA Checklist.
 
After inclusion, CAs must disclose their subordinate CAs in the [https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F Common CA Database], and maintain annual updates to the corresponding CP/CPS documents and audit statements.


== Distributing Generated Private Keys in PKCS#12 Files ==
== Distributing Generated Private Keys in PKCS#12 Files ==
Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925

edits

Navigation menu