[cabf_validation] Draft Ballot SCXX: Improve Certificate Lifetimes

[Jacob Hoffman-Andrews]

Let's Encrypt would like to co-sponsor this ballot. We've issued
certificates with a maximum lifetime of 90 days since 2015, and have found
that it works well, and is good for ecosystem security and reliability.

Shorter certificate lifetimes encourage Subscribers to automate their
issuance and installation workflow. This helps reliability by reducing
missed renewals caused by someone forgetting to renew on time. That, in
turn, improves security because Relying Parties are less likely to see
expired certificate warnings. Fewer warnings means that Relying Parties
don't start ignoring the warnings and clicking through. Less click-through
on warnings means that more data is properly secured by certificates,
increasing the value of certificates overall.

Shorter certificate lifetimes also reduce the impact of certificates issued
as a result of attacks (BGP hijacking, DNS credential compromise, etc).

Also, shorter certificate and validation lifetimes mean that when a
validation method turns out to be weak, it can be disabled and removed
quickly. For instance, we disabled the TLS-SNI-01 validation method in
March. I am very happy to be able to say with confidence that every
currently valid Let's Encrypt certificate has been validated with a
stronger method. And I can say that due to short certificate and validation
lifetimes.

I'll also note that the ecosystem has changed a lot since 2015. It used to
be the case that Subscribers were reluctant to automate any part of
certificate deployment because it was considered risky. There are now many
more solutions for automating deployment safely, and much more
understanding among Subscribers of the benefits that automation brings. So
I think the ecosystem is ready for shorter lifetimes.

On Fri, Jul 26, 2019 at 8:53 AM Ryan Sleevi via Validation <
validation at cabforum.org> wrote:

> As discussed on the last validation call, and previously at the CA/Browser
> Forum F2F, I've provided a draft ballot redline [1] to improve the
> certificate lifetimes. This is created as a Draft Pull Request to allow
> others to point out issues, and the current fixed commit version is [2],
> since [1] will be updated if/as feedback is received.
>
> This Ballot modifies the Baseline Requirements and EV Guidelines to
> harmonize on a 397-day Validity Period on 1 March 2020, two years after the
> adoption of the 825-lifetime of Ballot 193 (and subsequently modified by
> Ballot 197).
>
> A few explanations:
> - The choice of 397 days represents the maximum legitimate interpretation
> of a "thirteen-month" period; it's calculated from 366 days (considering
> leap years) along with a 31-day month, the longest in the calendar used by
> certificates.
> - It harmonizes the EV Guidelines with the BR Requirements, given that
> since 1 March 2018, the two have been aligned in their upper-bounds.
> - It clarifies the existing EV Guidelines "thirteen month" to a 397-day
> period, to both remove ambiguity and to harmonize expectations. This
> /should/ be a no-op, unless some CAs have been misinterpreting "thirteen
> months" as meaning that they could consider 1 Jan 2018 - 28 Feb 2019 as
> "thirteen months" ("occurring in the thirteenth month")
> - It resolves one area that had been flagged for cleanup; namely, Ballots
> 193 & 197 left a linguistic ambiguity in BRGs Section 6.3.2 with respect to
> what the maximally permitted validity period was/is exactly on 1 March 2018
> (with interpretations proffered of "no restrictions", "39 months", and "825
> days"). As a practical matter, root programs interpreted and enforced this
> requirement as 825 days, consistent with Section 4.2.1 which used the
> 'correct' language of "on or after"; this is largely a no-op considering
> it's in the past.
> - This also makes a minor correction to the EVGs Appendix F to correct
> "validity period" to its proper term "Validity Period"
>
> Other changes considered, but not incorporated in this draft:
> - An area of ambiguity that has been raised by CAs is whether or not
> fractional days "count". That is, if a certificate is issued on 2020-03-01
> 00:00:00, is the maximum permissible validity period 2021-04-02 00:00:00 or
> is it 2021-04-02 23:59:59?
>   - I'm firmly of the view that "fractional days mean greater than 0 days"
> and thus 23:59:59 would be a validity period exceeding 397 days (aka a
> violation of the requirement)
>   - This seems to be consistent with some members past explanations and
> interpretations. For example, in the past, some CAs have suggested that we
> clarify such periods based on seconds; for example "397 days, measured as
> 86400 second days" or some variation like that, which would align how root
> programs are computing and enforcing such periods
>   - If folks are concerned about CAs being tripped up on this, I'm happy
> to incorporate language that folks may wish to suggest to clarify that
> fractional days count as exceeding the period specified.
> - This modifies the EVGs 9.4 to refer to the "Baseline Requirements".
> There are other sections nearby (e.g. 9.5 / 9.6) that refer to "Baseline
> requirements" (non-proper term). Those will be punted for spring cleaning.
>
> I'm curious for feedback on these proposed changes and looking for
> potential endorsers for providing a ballot to the CA/Browser Forum's Server
> Certificate Working Group as a whole.
>
>
> [1] https://github.com/cabforum/documents/pull/138/files
> [2]
> https://github.com/cabforum/documents/compare/master...sleevi:af8f70db71c8284e78fb5b907972e2062c60b14f
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190801/de688828/attachment.html>