CA/Required or Recommended Practices: Difference between revisions

← Older edit

CA/Required or Recommended Practices (view source)

Revision as of 20:20, 28 April 2025

850 bytes removed , 28 April

Updated based on single-purpose roots required by MRSP v.3.0

Bwilson

Confirmed users

546

edits

@@ Line 171: / Line 171: @@
 * If any corresponding certificate with the same serial number and issuer exists, and can not be verified to match the precertificate using the algorithms in RFC 6962, it will be considered misissued.
 * In examining historical issuance, the CA must consider both final certificates and precertificates, even if the precertificate did not ultimately result in the issuance of a certificate.
+=== Single-Purpose Root Certificates ===
+A single-purpose root is required. See https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#75-dedicated-root-certificates.
 == Recommended Practices ==
@@ Line 176: / Line 180: @@
 === CA Hierarchy ===
-A hierarchical structure of a single-purpose root with intermediate certificates (subordinate CAs) is preferred. The single top-level root's public certificate is supplied for Mozilla's root list; subordinate CA certificates (including other self-signed root CA certificates that chain to the trusted root) must be reported in the CCADB.
+The single top-level root's public certificate is supplied for Mozilla's root list; subordinate CA certificates (including other self-signed root CA certificates that chain to the trusted root) must be reported in the CCADB.
-CAs that issue certificates under multiple subordinate CAs (i.e. under a root CA whose CA certificate is being requested for inclusion) or under multiple CA hierarchies (i.e. rooted at multiple root CAs, one or more of whose certificates is being requested for inclusion) should provide additional information as noted:
+CAs that issue certificates under multiple different CA hierarchies (i.e. in an inclusion application with multiple root CAs with different purposes) should provide additional information as noted:
 * The CA should provide a graphical or textual description of the CA hierarchy or hierarchies, including which subordinates are under which root CAs.
-* The CA should indicate the general types of certificates (i.e. for SSL/TLS servers, email signing/encryption) issued by each subordinate CA under each root.
+* Where a CP/CPS applies to multiple CA hierarchies, the CA should indicate whether particular sections of the CP/CPS apply to different hierarchies and, if so, what the differences are.
-* Where a CP/CPS applies to multiple subordinate CAs and/or multiple CA hierarchies, the CA should indicate whether particular sections of the CP/CPS apply to different subordinates and/or hierarchies and, if so, what the differences are.
-We strongly recommend that CA operators use separate root CA certificates with separate public keys (or separate intermediate CA certificates with separate public keys under a single root) when issuing certificates for different purposes so that we or others may selectively enable or disable acceptance of certificates issued according to a particular use or policy, or may otherwise treat such certificates differently (e.g., in our products' user interfaces).
 === Document Handling of IDNs in CP/CPS ===
@@ Line 191: / Line 193: @@
 === Usage of Appropriate Constraints ===
-Root certificates in Mozilla's program can have either the Websites trust bit set, or the Email trust bit, or both. If only one of those bits is set, relying software will trust certificates in that hierarchy for only that purpose. Nevertheless, it is a best practice for the immediately-issuing intermediate certificate to also contain EKU constraints of either id-kp-serverAuth or id-kp-emailProtection as appropriate, such that if the trust status of the root ever changes (or is not enforced for some reason), the end-entity certificates are still appropriately constrained.
+Root certificates in Mozilla's program can have either the Websites trust bit set or the Email trust bit. If only one of those bits is set, relying software will trust certificates in that hierarchy for only that purpose. Nevertheless, intermediate CA certificates must also contain EKU constraints of either id-kp-serverAuth or id-kp-emailProtection, as appropriate, such that end-entity certificates are still appropriately constrained.
 === OCSP Responses ===
 Including additional, superfluous certificates in an OCSP response wastes bandwidth. Therefore, CA operators should limit certificates delivered to a single Authorized Responder certificate, when that is necessary.