-
-
Notifications
You must be signed in to change notification settings - Fork 607
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add CRL capabilities to issuance package #7300
Conversation
@aarongable, this PR appears to contain configuration changes. Please ensure that a corresponding deployment ticket has been filed with the new configuration values. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally looks great! Some minor proposals.
boulderProfile.Lints, | ||
time.Hour, | ||
issuance.CRLProfileConfig{ | ||
ValidityInterval: config.Duration{Duration: 216 * time.Hour}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it was @beautifulentropy who provided a nice distinction:
- period: a span of time, unanchored from any particular instance (i.e. a duration)
- interval: a span of time anchored to a specific beginning and end time
So ValidityPeriod
would be nice here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, except that "Validity Period" is defined by RFC 5280 as being a thing that applies to certificates only (i.e. between NotBefore and NotAfter), while "Validity Interval" is the term used by the BRs to speak about CRL and OCSP responses (i.e. between ThisUpdate and NextUpdate): https://github.com/cabforum/servercert/blob/main/docs/BR.md#4910-on-line-revocation-checking-requirements
89861bd
Co-authored-by: Phil Porada <[email protected]>
Move the CRL issuance logic -- building an x509.RevocationList template, populating it with correctly-built extensions, linting it, and actually signing it -- out of the //ca package and into the //issuance package. This means that the CA's CRL code no longer needs to be able to reach inside the issuance package to access its issuers and certificates (and those fields will be able to be made private after the same is done for OCSP issuance). Additionally, improve the configuration of CRL issuance, create additional checks on CRL's ThisUpdate and NextUpdate fields, and make it possible for a CRL to contain two IssuingDistributionPoint URIs so that we can migrate to shorter addresses. IN-10045 tracks the corresponding production changes. Fixes letsencrypt#7159 Part of letsencrypt#7296 Part of letsencrypt#7294 Part of letsencrypt#7094 Part of letsencrypt#7100
This was missed in letsencrypt#7300 Part of letsencrypt#7296
This was missed in letsencrypt#7300 Part of letsencrypt#7296
This was missed in letsencrypt#7300 Part of letsencrypt#7296
Move the CRL issuance logic -- building an x509.RevocationList template, populating it with correctly-built extensions, linting it, and actually signing it -- out of the //ca package and into the //issuance package. This means that the CA's CRL code no longer needs to be able to reach inside the issuance package to access its issuers and certificates (and those fields will be able to be made private after the same is done for OCSP issuance).
Additionally, improve the configuration of CRL issuance, create additional checks on CRL's ThisUpdate and NextUpdate fields, and make it possible for a CRL to contain two IssuingDistributionPoint URIs so that we can migrate to shorter addresses.
Fixes #7159
Part of #7296
Part of #7294
Part of #7094
Part of #7100
IN-10045 tracks the corresponding production changes.
DO NOT MERGE before #7285DO NOT MERGE before #7299