You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's a requirement that CRLs for Intermediate CAs have reason codes. Table 1.2.2 in the TLS BRs says "2020‐09‐30 7.2 and 7.3 All OCSP and CRL responses for Subordinate CA Certificates MUST include a meaningful reason code." That means that "0" or unspecified or blank is not allowed. But BR 7.2.2. is convoluted, confusing, and hard to parse. It says "When present (OID 2.5.29.21), MUST NOT be marked critical and MUST indicate the most appropriate reason for revocation of the Certificate. MUST be present unless the CRL entry is for a
Certificate not technically capable of causing issuance and either 1) the CRL entry is for a Subscriber Certificate subject to these
Requirements revoked prior to July 15, 2023 or 2) the reason for revocation (i.e., reasonCode) is unspecified (0). See the “CRLReasons” table for additional requirements."
Section 7.3 (OCSP profile) is a little more clear, but needs to be improved, too. It says, "If an OCSP response is for a Root CA or Subordinate CA Certificate, including Cross‐Certified Subordinate CA Certificates, and that certificate has been revoked, then the revocationReason field within the RevokedInfo of the CertStatus MUST be present.
The CRLReason indicated MUST contain a value permitted for CRLs, as specified in Section 7.2.2."
In other words, for CAs the revocation reason code must be present and must be one of:
keyCompromise (1)
cACompromise (2)
affiliationChanged (3)
superseded (4)
cessationOfOperation (5)
The text was updated successfully, but these errors were encountered:
Hi Ben,
I agree that the text in the BR is hard to read. Regarding the Reason Codes for CA certificates in the CA Revocation List (CARL) I refer (in addition to the BR) to the X.509 standard which explains the meaning of the different reason codes in chapter 9.5.3.1 Reason code extension.
When reading the definitions in the BR and in the X.509 standard the meaningful reason codes for revoked CA certificates are
cACompromise (2) and
cessationOfOperation (5).
keyCompromise (1) is specifically mentioning the use for end-entity certificates, and the other reasons are seam end-entity targeted as well.
Recommendation: Create two subsections in order to specify which revocation reasons are allowed for revoked CA Certificates and end-entity Certificates
It's a requirement that CRLs for Intermediate CAs have reason codes. Table 1.2.2 in the TLS BRs says "2020‐09‐30 7.2 and 7.3 All OCSP and CRL responses for Subordinate CA Certificates MUST include a meaningful reason code." That means that "0" or unspecified or blank is not allowed. But BR 7.2.2. is convoluted, confusing, and hard to parse. It says "When present (OID 2.5.29.21), MUST NOT be marked critical and MUST indicate the most appropriate reason for revocation of the Certificate. MUST be present unless the CRL entry is for a
Certificate not technically capable of causing issuance and either 1) the CRL entry is for a Subscriber Certificate subject to these
Requirements revoked prior to July 15, 2023 or 2) the reason for revocation (i.e., reasonCode) is unspecified (0). See the “CRLReasons” table for additional requirements."
Section 7.3 (OCSP profile) is a little more clear, but needs to be improved, too. It says, "If an OCSP response is for a Root CA or Subordinate CA Certificate, including Cross‐Certified Subordinate CA Certificates, and that certificate has been revoked, then the revocationReason field within the RevokedInfo of the CertStatus MUST be present.
The CRLReason indicated MUST contain a value permitted for CRLs, as specified in Section 7.2.2."
In other words, for CAs the revocation reason code must be present and must be one of:
keyCompromise (1)
cACompromise (2)
affiliationChanged (3)
superseded (4)
cessationOfOperation (5)
The text was updated successfully, but these errors were encountered: