Changes

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., 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 indicate the general types of certificates (i.e., for SSL/TLS servers, email signing/encryption, and code signing) issued by each subordinate CA under each root.

We also strongly recommend that CAs consider using 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 according to for different Certificate Policies, 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).

Recently, several Several tools have been developed exist ([https://github.com/awslabscertlint/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.

The current implementation of Mozilla recommends that CAs log TLS precertificates using [https://www.certificate-transparency.org/ Certificate Transparency] does not provide any way (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 Relying Parties to determine if a certificate corresponding purposes of determining CA compliance. CAs must be able to a given precertificate has or has not been issuedrevoke precertificates. It Mozilla is only safe to assume also planning on requiring that a certificate corresponding to every precertificate existsTLS precertificates be logged in CT.