Confirmed users
377
edits
CA/Required or Recommended Practices: Difference between revisions
Jump to navigation
Jump to search
CA/Required or Recommended Practices (view source)
Revision as of 00:11, 22 October 2022
, 22 October 2022→Recommended Practices: Updated for current version of MRSP
m (→Network Security Controls: Minor) |
(→Recommended Practices: Updated for current version of MRSP) |
||
| Line 157: | Line 157: | ||
=== CA Hierarchy === | === CA Hierarchy === | ||
A hierarchical structure of a single 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. | 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. | ||
CAs that issue certificates under multiple subordinate CAs (i.e. | 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: | ||
* 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 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. | * 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 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. | * 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 | 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 === | === Document Handling of IDNs in CP/CPS === | ||
| Line 176: | Line 176: | ||
=== Pre-Issuance Linting === | === Pre-Issuance Linting === | ||
Several tools exist ([https://github.com/certlint/certlint certlint/cablint], [https://github.com/kroeckx/x509lint x509lint], [https://github.com/zmap/zlint zlint]) which can check a tbsCertificate (To Be Signed Certificate - the certificate complete except for the signature) for a large number of standards violations (BRs, RFCs etc.). It is strongly recommended that CAs integrate such tools into their issuance pipelines such that issuance is, minimally, held up for manual review if an error or warning is found. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences, if earlier parts of their pipeline fail in their job of keeping certificates compliant. | |||
=== Precertificates === | === Precertificates === | ||
Mozilla recommends that CAs log TLS precertificates using [https://www.certificate-transparency.org/ Certificate Transparency] (CT). CAs should be aware of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#54-precertificates section 5.4 of the Mozilla Root Store Policy], and that Mozilla considers logged precertificates as certificates for purposes of determining CA compliance. CAs must be able to revoke precertificates. Mozilla is also planning on requiring that TLS precertificates be logged in CT. | |||
[https://datatracker.ietf.org/doc/html/rfc9162#section-3.2.1 Section 3.2.1 of RFC 9162] states “a precertificate's signature indicates the CA's binding intent to issue the corresponding certificate, which means that: Misissuance of a precertificate is considered equivalent to misissuance of the corresponding certificate. The CA should expect to be held accountable, even if the corresponding certificate has not actually been issued." | [https://datatracker.ietf.org/doc/html/rfc9162#section-3.2.1 Section 3.2.1 of RFC 9162] states “a precertificate's signature indicates the CA's binding intent to issue the corresponding certificate, which means that: Misissuance of a precertificate is considered equivalent to misissuance of the corresponding certificate. The CA should expect to be held accountable, even if the corresponding certificate has not actually been issued." | ||