[cabf_validation] Draft Ballot SCXX: Improve Certificate Lifetimes

Thu Aug 1 08:55:58 MST 2019

Ryan,

GlobalSign is not in favor of this ballot for a number of reasons, but maybe some changes or improved reason for your changes will help.

Over the past several years, this topic has come up many times and the proponents have made their cases.  What would help us is a consolidated set of security/ecosystem benefits of this change.  I know you’ve provided lots of reasons in the past, but a static blog or announcement page with the complete set of driving reasons would help everyone understand exactly where you’re coming from.  We can use this as we communicate the change to our customers and then everyone has the same understanding of the importance of this change.

This ballot proposes changes to several components and not just the maximum validity period.  I’d like to understand the reasons for each, perhaps in the above proposed blog.

*	Maximum validity period: Yes, this is the driving reason for the ballot, I understand that.
*	Maximum re-use of domain validation data: Is limiting this to 13 months necessary?  If this is the primary reason for the ballot, then is the reduction in certificate validity necessary?  How do these 2 changes relate to each other?  Do these have to match, and if so, why?
*	Maximum reuse of Organizational data: Is this necessary to be done every 13 months?  Would you accept a proposal of keeping this at 27 months while reducing the above 2 items?
*	What’s special about 13 months, vs, say 20 months (splitting the difference)?  Can we have a more gradual reduction in the validity periods over the next ~3 years to get down to 12 or 13 months?

If/when the changes to domain validation and organizational data re-use go into effect, I hope that domains/organizations verified prior to a certain date can have the data re-use for the full 27 months and that on the effective date, new validations must not be re-used for longer than the new date.  This effective date can even be prior to the reduction of the maximum certificate validity period.  We want to avoid a cliff where customers and CAs have a mass number of domain and OrganizationSSL verifications to do all at once.  Been there, let’s not do that again.

Doug

From: Validation <validation-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Validation
Sent: Friday, July 26, 2019 11:53 AM
To: CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: [cabf_validation] Draft Ballot SCXX: Improve Certificate Lifetimes

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190801/0744347b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5701 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20190801/0744347b/attachment-0001.p7s>