[cabf_validation] Draft Ballot SCXX: Improve Certificate Lifetimes

Ryan Sleevi sleevi at google.com
Fri Jul 26 08:52:59 MST 2019

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
- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190726/8595ee2a/attachment.html>

More information about the Validation mailing list