[cabf_validation] Draft Ballot SCXX: Improve Certificate Lifetimes

[Wayne Thayer]

I'd suggest that the Validity Period requirement for .onion certs in
Appendix F be modified as follows to eliminate any potential
confusion/misinterpretation:

> Prior to March 1, 2020, CAs MUST NOT issue a Certificate that includes a
Domain Name where .onion is in the right-most label of the Domain Name with
a Validity Period longer than 15 months.

Otherwise, one logical interpretation of this requirement after the
effective date is that it overrides the 397 day limit. I don't think that's
the intent.

- Wayne

On Fri, Jul 26, 2019 at 8:53 AM Ryan Sleevi <sleevi at google.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190726/9b52cfd4/attachment.html>