CA/Required or Recommended Practices: Difference between revisions

Jump to navigation Jump to search

CA/Required or Recommended Practices (view source)

Revision as of 17:52, 13 August 2024

287 bytes added ,  13 August 2024
Moved Pre-issuance Linting and Precertificates to Required Practice section and added new OCSP "SHOULD" to Recommended Practices
(→‎Complete Audit History: Replaced point-in-time audits with concept of period-of-time key lifecycle management reports)
(Moved Pre-issuance Linting and Precertificates to Required Practice section and added new OCSP "SHOULD" to Recommended Practices)
Line 153: Line 153:
* Ensure Intrusion Detection System and other monitoring software is up-to-date.
* Ensure Intrusion Detection System and other monitoring software is up-to-date.
* Confirm the ability to shut down certificate issuance quickly if alerted of intrusion.
* Confirm the ability to shut down certificate issuance quickly if alerted of intrusion.
=== Pre-Issuance Linting ===
Several tools are available on GitHub to check a tbsCertificate (To Be Signed Certificate - the certificate complete except for the signature): [https://github.com/pkimetal/pkimetal PKI Meta-Linter], [https://github.com/digicert/pkilint PKI Lint], [https://github.com/certlint/certlint certlint/cablint], [https://github.com/kroeckx/x509lint x509lint], [https://github.com/zmap/zlint zlint], for a large number of standards violations (BRs, RFCs etc.). Ballot SC-075 requires that CAs integrate pre-issuance linting into their issuance pipelines by March 15, 2025. 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 ===
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."
While [https://cabforum.org/baseline-requirements-documents/ BR] section 7.1.2.5 states “For purposes of clarification, a Precertificate, as described in RFC 6962 – Certificate Transparency, shall not be considered to be a “certificate” subject to the requirements of RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile under these Baseline Requirements”, Mozilla [https://cabforum.org/pipermail/public/2014-January/002694.html interprets] the BR language as a specific exception allowing CAs to issue a precertificate containing the same serial number as the subsequent certificate. Otherwise, Mozilla infers from the existence of a precertificate that a corresponding certificate has been issued.
Application of RFC 9162 means that:
* A CA must provide OCSP services and responses in accordance with Mozilla policy for all certificates presumed to exist based on the presence of a precertificate, even if the certificate does not actually exist
* A CA must be able to revoke a certificate presumed to exist, if revocation of the certificate is required under Mozilla policy, even if the certificate does not actually exist.
* 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.


== Recommended Practices ==
== Recommended Practices ==
Line 173: Line 191:
=== Usage of Appropriate Constraints ===
=== 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, 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.  
 
=== 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 ===
 
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."
=== OCSP Responses ===
While [https://cabforum.org/baseline-requirements-documents/ BR] section 7.1.2.5 states “For purposes of clarification, a Precertificate, as described in RFC 6962 – Certificate Transparency, shall not be considered to be a “certificate” subject to the requirements of RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile under these Baseline Requirements”, Mozilla [https://cabforum.org/pipermail/public/2014-January/002694.html interprets] the BR language as a specific exception allowing CAs to issue a precertificate containing the same serial number as the subsequent certificate. Otherwise, Mozilla infers from the existence of a precertificate that a corresponding certificate has been issued.


Application of RFC 9162 means that:
Including additional, superfluous certificates in an OCSP reponse wastes bandwidth. Therefore, CA operators should limit certificates delivered to a single Authorized Responder certificate, when that is necessary.
* A CA must provide OCSP services and responses in accordance with Mozilla policy for all certificates presumed to exist based on the presence of a precertificate, even if the certificate does not actually exist
* A CA must be able to revoke a certificate presumed to exist, if revocation of the certificate is required under Mozilla policy, even if the certificate does not actually exist.
* 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.
Bwilson
Confirmed users
569

edits

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

Navigation menu