-
Notifications
You must be signed in to change notification settings - Fork 106
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
Computation of validity period is incorrect #608
Comments
(FYI, I'm happy to tackle fixing this, just wanted to get all the details down in a bug before opening PRs.) |
@aarongable I believe this is similar to the Chrome issue you filed, namely https://bugs.chromium.org/p/chromium/issues/detail?id=1217920 The context being that there were existing lints that used the old BR definitions. The new lints that were added for 398 day certs - also part of SC31 - use the definition that accompanied that ballot |
RFC 5280, Section 4.1.2.5, says:
This means that a certificate with a notBefore timestamp of 2021-01-01 01:01:01 GMT and a notAfter timestamp of 2021-01-01 02:01:01 GMT actually has a "validity period" of 1 hour and one second.
The Baseline Requirements, Section 6.3.2, say:
When zlint calculates the validity period of a certificate (in the apple, cabf_br, and ev versions of the 825_days and 39_months lints) it does so using this computation:
zlint/v3/lints/cabf_br/lint_sub_cert_valid_time_longer_than_825_days.go
Line 45 in 7e75dc3
In other words, it adds 825 days to the
notBefore
, and checks to see if that date falls before thenotAfter
. This does not account for the maximum validity period being inclusive of the time represented by thenotAfter
timestamp.I have created a pair of tests. The first one uses a certificate with a lifetime of exactly 825 days, inclusive, and passes:
The second one uses a certificate with a validity period of 825 days and one second, which should be rejected, but the test fails as zlint sees no problem with this certificate:
You can see both tests here: master...aarongable:validity-period-tests
Unfortunately, fixing this is not as trivial as simply offsetting the calculation by one second. Per RFC 5280, the
notBefore
andnotAfter
timestamps may be encoded either as UTCTime or as GenralizedTime (with requirements on which is used based on the date being represented). Unfortunately, UTCTime allows timestamp granularity of either seconds or minutes. Meaning that a fully correct implementation of this must determine the granularity of the timestamp and perform the inclusive validity time computation accordingly.The text was updated successfully, but these errors were encountered: