This is going to break zlint output for certificates issued before 2023-09-15 which might affect some use cases like crt.sh. I think it might make more sense here to mark the existing lint ineffective at CABFBRs_2_0_0_Date and copy this code into a new lint that enforces only the new, unmixed version of the requirement.

I see what you mean, I’ll split these into separate lints.

My only concern is that over time, each directory may accumulate a large number of lints that have been ineffective for years (e.g., 3+ years old). Is there a plan or policy for how long to keep ineffective lints around before cleaning them up or is the plan to always be backwards compatible with old requirements?

Is there a plan or policy for how long to keep ineffective lints around before cleaning them up or is the plan to always be backwards compatible with old requirements?

I suppose that that depends on...

1. What is out there in the wild
2. The audience of ZLint

For #1, as certs expire their sunsetted requirements will naturally become irrelevant. That'll be much easier over the course of the next decade as shorter-and-shorter lifecycles not only become the norm, but are enforced. In the meantime, I would not be surprised to find many 10 year+ certificates.

For #2, it depends on whether the audience of ZLint cares to scrutinize old certificates with such long life cycles. I would hazard a guess that most industry users are more concerned with the now-rather-than-the-then. Although researchers may have an interest in the "wild side" of the older web PKI.