[cabf_validation] Draft Ballot SCXX: Improve Certificate Lifetimes

Fri Aug 2 18:37:28 MST 2019

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> 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> 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> im Auftrag von Jacob
> Hoffman-Andrews via Validation <validation at cabforum.org>
> *Antworten an: *Jacob Hoffman-Andrews <jsha at letsencrypt.org>, CA/Browser
> Forum Validation WG List <validation at cabforum.org>
> *Datum: *Donnerstag, 1. August 2019 um 20:22
> *An: *Ryan Sleevi <sleevi at google.com>, CA/Browser Forum Validation WG
> List <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> 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
>
> _______________________________________________
> 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/548a944e/attachment-0001.html>