[cabf_validation] Draft Ballot SCXX: Improve Certificate Lifetimes

Fri Aug 2 17:56:45 MST 2019

Apple is supportive of this proposal and will endorse it with some additional clarification in an implementation note or some other addressing of the issue of the partial day ambiguity.

We believe that the 397-day Validity Period provides security and operational benefits to subscribers that outweigh the disadvantages — benefits that we have seen in our own environments as we’ve transitioned towards shorter Validity Periods. 
Security:
- Long lived certs present a longer lived threat. We have seen this presented in the BygoneSSL report/brief. We would like to work towards having the domain validation validity align with the certificate validity.
- Since most software fails open when performing revocation checks, the best safeguard is the validity period of the certificate.
Operational:
- Teams with high turnover are better able to ensure continuity.
- Teams align other annual requirements with certificate issuance so that manual issuances aren’t forgotten.
- Encourages adoption of automation that reduces opportunity for human error and reduces operational cost overall.

We’re concerned that using a 13-month period for the freshness of validation data with a 397-day certificate Validity Period poses some risk because it allows issuance of the original certificate and the subsequent renewal using the same data. For example, if a 12-month Validity Period certificate is issued the day the data is validated, at renewal time that same validation data has still ~ 30 days of freshness under which the renewal certificate can be issued. We would like to see this issue addressed in this or a subsequent ballot.

Curt

> On Aug 1, 2019, at 2:01 PM, Dean Coclin via Validation <validation at cabforum.org> wrote:
> 
> 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 <https://github.com/cabforum/documents/pull/138/files>
> [2] https://github.com/cabforum/documents/compare/master...sleevi:af8f70db71c8284e78fb5b907972e2062c60b14f <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 <https://cabforum.org/mailman/listinfo/validation>_______________________________________________
> 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/20190802/47ae04d5/attachment-0001.html>