[cabf_validation] Draft Ballot SCXX: Improve Certificate Lifetimes

Mon Aug 5 10:37:18 MST 2019

Ryan,

Sectigo is willing to endorse this ballot, but we have a couple of concerns, primarily around (1) timing of implementation and (2) future validity period changes.  

Before getting into the details of those concerns we would like to thank you for bringing this to the Forum rather than going it alone as some trust store operators have done with significant policy changes in the recent past.  While we acknowledge that trust store operators are not obligated to do so, we feel it's very important that in general, and barring serious and immediate security concerns, policy changes take place in the CA/B Forum in order to foster the continued cooperation between CAs and trust store operators.  

Timing of implementation:

We've been reaching out to customers to get feedback, and what’s coming back is concern that March may be too soon for some of our customers, large enterprises and resellers, to prepare for this kind of change, so we'd like to push implementation date out to September 1, 2020. 

Future validity period changes:

Since the validity period has been discussed for quite some time, and has been somewhat contentious, we hope to gain an understanding and possibly consensus about how changes to it in the future are viewed.  Our thinking is that due to the non-trivial downstream impact to enterprises that result from the changes that we make, we have to carefully weigh how frequently the validity period should be changed.  Barring significant and immediate security concerns, we’d like all parties to consider calling certificate validity settled for 3 to 5 years after this ballot. Note that this does not include discussion of modifications of data re-use validity to address issues which have come up in discussion of this ballot.

Regards,

Rich

From: Validation <validation-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Validation
Sent: Friday, August 2, 2019 8:37 PM
To: Curt Spann <cspann at apple.com>
Cc: CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] Draft Ballot SCXX: Improve Certificate Lifetimes

Thanks Curt!

Those are all great reasons!

I've been thinking about how to bring that clarity, and I'm curious if the following would address the concern:

- Define the maximum Validity Period as 398 days, rather than 397

- Change the requirements around validity period to say that CAs SHOULD NOT issue certificates with Validity Periods greater than 34300800 seconds, which is 397 days of 86,400 seconds, and MUST NOT issue certificate with Validity Periods greater than 34387200 seconds, which is 398 days of 86,400 seconds.

  - This attempts to define validity periods unambiguously in number of seconds

  - But to allow for leap seconds, time zone changes, and 'reasonable' mistakes, sets the MUST NOT at 398 days. Any CA that implements their system using 397 days correctly will be hard pressed to violate the MUST NOT, but that gives a little room to handle the messiness of dates.

I agree, your concern about the combination of (expiration + reuse) basically doubling the staleness period for information is concerning. I think we can and should reduce that, and I think it'd be great follow-on work to explore, as I was mentioning earlier in the thread. Would you be open to a (non-binding, non-normative) roadmap and timeline that we could share with this ballot, and then work on subsequent ballots to capture those timelines in the BRs?

On Fri, Aug 2, 2019 at 8:57 PM Curt Spann <cspann at apple.com <mailto:cspann at apple.com> > wrote:

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 <mailto: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 <mailto:ch at psw.net> > 
Sent: Thursday, August 1, 2019 4:24 PM
To: 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> >
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

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