Clarify when it's acceptable to "backdate" a CRL entry

[ryancdickson]

Background:

• SC-61 introduced the following language to Section 7.2.2 in Version 1.8.7 of the TLS BRs:
  "Backdating the revocationDate field is an exception to best practice described in RFC 5280 (section 5.3.2); however, these requirements specify the use of the revocationDate field to support TLS implementations that process the revocationDate field as the date when the Certificate is first considered to be compromised."
  
  

Issue:

• While "implementations that process the revocationDate field as the date when the Certificate is first considered to be compromised" applies to a use case like Code Signing, it does not appear applicable to TLS.
• Further, RFC 5280 describes revocationDate as "The date on which the revocation occurred is specified." "invalidityDate" ("the date on which it is known or suspected that the private key was compromised or that the certificate otherwise became invalid", RFC 5280) would serve as a better expression of when a certificate is first considered compromised.
  
  

Proposal:

• We should clearly define backdating such that the practice is unambiguous. For example, in the case of revocation, backdating could be considered any time when the revocationDate is set to a date and time prior to the date when a certificate's status was first changed from valid to revoked.
• We should clearly define when it's acceptable to perform backdating. Known use cases include:
  • to convey that a serial # included within a pre-certificate (where no "final" certificate was issued) was never trusted (set the revocationDate to the pre-certificate's notBefore date)
  • to allow a revocation reasonCode to be updated, without suggesting the date of revocation changed (e.g., assume a certificate was revoked on 10/1/2022 at 00:00:00 GMT with a reasonCode of "cessationOfOperations," but on 12/1/2022 00:00:00 GMT the CA learned the reasonCode should have been "keyCompromise." The CA should be free to change the reasonCode without changing the revocationDate.

Goals for this update: reduce ambiguity and clarify expectations

[timfromdigicert]

Unfortunately, invalidityDate is not widely used or supported, which is why backdated revocations are generally done using the revocationDate.

I do support additional clarity in this area, though, as the use cases for TLS are pretty limited.

-Tim

From: Ryan Dickson @.> Sent: Friday, June 16, 2023 10:28 AM To: cabforum/servercert @.> Cc: Subscribed @.***> Subject: [cabforum/servercert] Clarify when it's acceptable to "backdate" a CRL entry (Issue #437)

Background:

• SC-61 introduced the following language to Section 7.2.2 in Version 1.8.7 of the TLS BRs:

"Backdating the revocationDate field is an exception to best practice described in RFC 5280 (section 5.3.2); however, these requirements specify the use of the revocationDate field to support TLS implementations that process the revocationDate field as the date when the Certificate is first considered to be compromised."

Issue:

• While "implementations that process the revocationDate field as the date when the Certificate is first considered to be compromised" applies to a use case like Code Signing, it does not appear applicable to TLS.
• Further, RFC 5280https://datatracker.ietf.org/doc/html/rfc5280#section-5.1.2.6 describes revocationDate as "The date on which the revocation occurred is specified." "invalidityDate" ("the date on which it is known or suspected that the private key was compromised or that the certificate otherwise became invalid", RFC 5280https://datatracker.ietf.org/doc/html/rfc5280#section-5.3.2) would serve as a better expression of when a certificate is first considered compromised.

Proposal:

• We should clearly define backdating such that the practice is unambiguous. For example, in the case of revocation, backdating could be considered any time when the revocationDate is set to a date and time prior to the date when a certificate's status was first changed from valid to revoked.

• We should clearly define when it's acceptable to perform backdating. Known use cases include:

  • to convey that a serial # included within a pre-certificate (where no "final" certificate was issued) was never trusted (set the revocationDate to the pre-certificate's notBefore date)
  • to allow a revocation reasonCode to be updated, without suggesting the date of revocation changed (e.g., assume a certificate was revoked on 10/1/2022 at 00:00:00 GMT with a reasonCode of "cessationOfOperations," but on 12/1/2022 00:00:00 GMT the CA learned the reasonCode should have been "keyCompromise." The CA should be free to change the reasonCode without changing the revocationDate.

Goals for this update: reduce ambiguity and clarify expectations

— Reply to this email directly, view it on GitHubhttps://github.com/cabforum/servercert/issues/437, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIFREHF5SRJAP43J32VV4JTXLRUNVANCNFSM6AAAAAAZJKZU5Q. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[BenWilson-Mozilla]

Skipped during Server Certificate Working Group July 18, 2024.