[cabf_validation] FW: Draft Ballot SCXX: Improve Certificate Lifetimes

Thu Aug 1 14:01:55 MST 2019

Forwarding to the list. He has signed the IPR previously and am working with the chair to enable posting…

From: Christian Heutger <ch at psw.net> 
Sent: Thursday, August 1, 2019 4:24 PM
To: Jacob Hoffman-Andrews <jsha at letsencrypt.org>; CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] Draft Ballot SCXX: Improve Certificate Lifetimes

Totally disagree. Automation is against all security best practices and it’s the only way to handle short lifetimes. Maybe on private installation you may encountered success with ACME, but I’ve never seen any Enterprise installations, which use complex infrastructures to use automation on critical systems.

Against attacks there exist techniques like OCSP, so they should be optimized instead of working them around with solutions, which only work on particular user bases.

Von: Validation <validation-bounces at cabforum.org <mailto:validation-bounces at cabforum.org> > im Auftrag von Jacob Hoffman-Andrews via Validation <validation at cabforum.org <mailto:validation at cabforum.org> >
Antworten an: Jacob Hoffman-Andrews <jsha at letsencrypt.org <mailto:jsha at letsencrypt.org> >, CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org> >
Datum: Donnerstag, 1. August 2019 um 20:22
An: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> >, CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org> >
Betreff: Re: [cabf_validation] Draft Ballot SCXX: Improve Certificate Lifetimes

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 <mailto: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 <mailto: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/49aa1503/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4916 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20190801/49aa1503/attachment-0001.p7s>