Add lint to check CRLs for a valid nextUpdate as per CABF BRs#916
Merged
christopher-henderson merged 36 commits intozmap:masterfrom Feb 16, 2025
Merged
Add lint to check CRLs for a valid nextUpdate as per CABF BRs#916christopher-henderson merged 36 commits intozmap:masterfrom
christopher-henderson merged 36 commits intozmap:masterfrom
Conversation
Added //nolint:all to comment block to avoid golangci-lint to complain about duplicate words in comment
Fixed import block
Fine to me. Co-authored-by: Christopher Henderson <[email protected]>
As per Chris Henderson's suggestion, to "improve readability".
As per Chris Henderson's suggestion.
Added CABFEV_Sec9_2_8_Date
christopher-henderson
approved these changes
Feb 16, 2025
| LintMetadata: lint.LintMetadata{ | ||
| Name: "e_crl_next_update_invalid", | ||
| Description: "For CRLs covering (EE|CA) certificates, nextUpdate must be at most (10 days|12 months) beyond thisUpdate", | ||
| Citation: "Section 4.9.7 of BRs v1.8.7 (then section 7.2 since BRs v2.0.0)", |
There was a problem hiding this comment.
(then section 7.2 since BRs v2.0.0) Thank you 😭 it is super painful sometimes to go hunting for wording that may have changed just enough to sabotage a raw text search.
| config string | ||
| want lint.LintStatus | ||
| } | ||
| data := []Data{ |
There was a problem hiding this comment.
As always, thank you for the comprehensive test suite. These check out against my own expectations.
aarongable
added a commit
to letsencrypt/boulder
that referenced
this pull request
Aug 22, 2025
Zlint has added more lints, some of which (like zmap/zlint#916) are insufficiently smart and can't tell the difference between a Subscriber CRL and a Root CRL. We need the ability to skip lints like this, so give the CRL ceremony the same capability as we already have for our various certificate ceremonies.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Already in the CABF TLS BRs v1.8.7 there was a requirement about the maximum lifespan (the time span between
thisUpdateandnextUpdate) of CRLs, but until now there was no corresponding check in Zlint. The lint I am proposing here returns an error if this limit is exceeded in the CRL under examination.It should be noted that the BRs set different lifespan limits depending on whether the CRL covers Subscriber certs (max 10 days) vs. CA certs (max 12 months), but since it is not possible to distinguish the two cases without a context, I implemented the "Configure" interface in this lint. By default, this lint assumes that the input CRL is one that covers Subscriber certs; if you want to specify that it covers CA certs instead, you need to pass Zlint (via the -config option) a TOML file containing the following configuration: