I think it makes sense to implement the certlint approach, which is maximally permissive without being stupidly liberal (e.g. assuming 3 years is 3 * 31 days ;P)

I'm tempted to suggest that we should also consider our CT enforcement, which does a similar 'month' based check, to be similar. I believe, but would feel better if someone else confirmed, that these day-based interpretations would be more permissive than the current implementation in all cases, and thus not represent any compatibility risk.

+1 for simplifying, using certlint's approach.

For CT (code: https://cs.chromium.org/chromium/src/net/cert/ct_policy_enforcer.cc?type=cs&l=329), I believe that the day-based interpretations would be more permissive than the current implementation, not representing any compatibility risk.

The table in https://github.com/GoogleChrome/ct-policy/blob/master/ct_policy.md
 would convert to:
< 465 days, 2 SCTs
>= 465 days, <= 837 days, 3 SCTs
> 837 days, <= 1209 days, 4 SCTs
> 1209 days, 5 SCTs

As far as I can tell, the interpretation of month as 31 days would mean existing certs will match the same line they matched in the months table, or the previous line.

For example, a validity period between 2017-02-28 and 2020-05-30 would be considered by the current code to require 5 SCTs (having validity period of 39 months + partial month), but, being 1187 days long, will match the 3rd row on the table, requiring only 4 SCTs.

@eranm: Apologies I wasn't clearer. I think "month as 31 days" was the stupidly liberal approach, compared to the more principled approach taken in Certlint :)

Certlint looks at "What the maximum possible range of X months is". For example, for a 39 month range, he assumed a leap year was one of the years (as that has 366 days) and that the range of 3 months where they are longest (July/Aug/Sept) as 31+31+30. So you end up with 366 + 365 + 365 + 31 + 31 + 30 (+1 for rounding).

So 15 months = 366 + 31 + 31 + 30 = 458
27 months = 366 + 365 + 31 + 31 + 30 = 823
39 months = 366 + 365 + 365 + 31 + 31 + 30 = 1188

(and then add 1 day for rounding).

This is less than a 15 * 31 approach, but as far as I can tell, greater than-or-equal-to our existing code.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fb6f866450dcb4623c08ca3bdf7ab08e4e992f57

commit fb6f866450dcb4623c08ca3bdf7ab08e4e992f57
Author: Ryan Sleevi <rsleevi@chromium.org>
Date: Sat Apr 07 03:55:38 2018

Simplify the certificate validity month calculations

Previously, the date calculation for determining if a certificate
had a too long validity was based on calculating a rounded difference
on the day portion of the date and the difference in months. This would
result in "rounding up" when calculating how many months were between
two dates.

With this change, the determination for whether a certificate has a
validity greater than the maximum permitted is based on the difference
in the number of days (accounting for leap years). Strictly speaking,
this loosens the strictness of enforcement, which means that additional
certificates may now be accepted that might otherwise not, but it
simplifies the computations and makes it less likely that an otherwise
valid certificate would be rejected due to rounding.

BUG= 713362 

Change-Id: I9577169588f285bd9e2afeee882838de404b1a56
Reviewed-on: https://chromium-review.googlesource.com/1000353
Commit-Queue: Ryan Sleevi <rsleevi@chromium.org>
Reviewed-by: Eric Roman <eroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549031}
[modify] https://crrev.com/fb6f866450dcb4623c08ca3bdf7ab08e4e992f57/net/BUILD.gn
[modify] https://crrev.com/fb6f866450dcb4623c08ca3bdf7ab08e4e992f57/net/cert/cert_verify_proc.cc
[modify] https://crrev.com/fb6f866450dcb4623c08ca3bdf7ab08e4e992f57/net/cert/cert_verify_proc_unittest.cc
[add] https://crrev.com/fb6f866450dcb4623c08ca3bdf7ab08e4e992f57/net/data/ssl/certificates/39_months_based_on_last_day.pem
[modify] https://crrev.com/fb6f866450dcb4623c08ca3bdf7ab08e4e992f57/net/data/ssl/scripts/generate-test-certs.sh

Marking Verified for M-67 for certificates. The CT change is separately being tracked in the CT repository as a policy issue first.

#713362