Changes

[https://toolsdatatracker.ietf.org/doc/html/rfc6962 rfc9162#section-3.2.1 Section 3.2.1 of RFC 69629162] states “The “a precertificate's signature on the TBSCertificate indicates the certificate authorityCA's binding intent to issue a the corresponding certificate. This intent is considered binding (i.e., misissuance which means that: Misissuance of the Precertificate a precertificate is considered equal equivalent to misissuance of the final corresponding certificate. The CA should expect to be held accountable, even if the corresponding certificate)has not actually been issued.”"

However, 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 RequirementsRequirements”, 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.”

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 Application of a precertificate that a corresponding certificate has been issued. This RFC 9162 means, for example, 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 Precertificateprecertificate, even if the certificate does not actually exist