Establish CRL "backdating" expectations

[ryancdickson]

A recently filed Incident Report highlighted the TLS BRs makes no stipulation regarding CRL backdating.

This issue was raised because two CA Owner's were identified issuing CRLs containing revoked certificate entries with a revocationDate after the thisUpdate field, which triggers this ZLint lint.

As described in the lint:

 * The thisUpdate field in a CRL indicates the time at which the CRL was issued.
 * For each entry in the revokedCertificates list within the CRL, there is a
 * revocationDate field. This revocationDate signifies when the certificate was revoked.
 * Logically, a certificate cannot be listed as revoked on a CRL with a revocationDate
 * that is after the thisUpdate of that CRL, because thisUpdate marks the point
 * in time that the information in the CRL is considered valid. If a revocation
 * happened after the CRL was issued, it would appear on a subsequent CRL.

IMO, CRL backdating makes less sense than Certificate backdating. Also, an undefined limit allows for practices that could go beyond compensating for clock skew. We should discuss the applicability of CRL backdating within the SCWG and either prohibit the practice or establish clearer expectations for what's permissible.

Proposal: Perhaps, if backdating is considered essential, there's an expectation that:

• It is limited to a strict threshold (e.g., less than XX minutes or hours); AND
• The thisUpdate date is no earlier than the revocationDate of the most recently revoked certificate contained in that CRL.

For reference, Certificate backdating appears discussed here and here.

[github-actions]

This issue was created based on:

• TLS BR Version 2.2.2
• EVG Version 2.0.1

[GreatAmus]

Backdating makes sense for code signing and timestamping but not for TLS. The CS working group will want to make sure this doesn't get pulled into the Baseline Requirements for CS.

I do agree that some backdating should be okay because of how CA systems are set up. Some of them seem to issue CRLs at the start of the day on which they are revoked (backdating to midnight at the start). That might be difficult to change. I think if you allow backdating by 24 hours you end up capturing those weird nuances without going overboard.

[XolphinMartijn]

@GreatAmus

Backdating makes sense for code signing and timestamping but not for TLS. The CS working group will want to make sure this doesn't get pulled into the Baseline Requirements for CS.

I don't believe we need to consider this. This ticket is related to the backdating of the CRL itself, not the crl entries themselves, which indeed is what the CSWG does care about.

[GreatAmus]

Oh - Thanks. I misread that. Has any CA doing this given a reason why? I'd be curious to hear from one of them on why they think its necessary.