Confirmed users
525
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 22:30, 10 January 2022
, 10 January 2022→Precertificates: Updated for RFC 9162
(→CP/CPS Documents will be Reviewed!: Added review of SECOM's CPs/CPSes) |
(→Precertificates: Updated for RFC 9162) |
||
| Line 255: | Line 255: | ||
The current implementation of [https://www.certificate-transparency.org/ Certificate Transparency] does not provide any way for Relying Parties to determine if a certificate corresponding to a given precertificate has or has not been issued. It is only safe to assume that a certificate corresponding to every precertificate exists. | The current implementation of [https://www.certificate-transparency.org/ Certificate Transparency] does not provide any way for Relying Parties to determine if a certificate corresponding to a given precertificate has or has not been issued. It is only safe to assume that a certificate corresponding to every precertificate exists. | ||
[https:// | [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 provide OCSP services and responses in accordance with Mozilla policy for all certificates presumed to exist based on the presence of a | |||
* 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. | * 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. | * 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. | * 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. | ||