[Servercert-wg] Discussion Period Begins: SC-52: Specify CRL Validity Intervals in Seconds

Mon Nov 22 16:36:18 UTC 2021

Thanks Aaron. I went ahead and added your commits to the pull request:
https://github.com/cabforum/servercert/pull/327

On Fri, Nov 19, 2021 at 2:20 PM Aaron Gable <aaron at letsencrypt.org> wrote:

> Fantastic, I've added my suggested edits for the "ignore leap seconds"
> solution to the PR that Wayne opened.
>
> Thanks!
> Aaron
>
> On Fri, Nov 19, 2021 at 12:10 PM Tim Hollebeek <tim.hollebeek at digicert.com>
> wrote:
>
>> Yeah, directionally, we support ignoring leap seconds, too.  We discussed
>> it a bit internally this morning.
>>
>>
>>
>> There’s some hilarious internal discussion that makes sense to get out
>> onto the public list for everyone’s enjoyment: it turns out that leap
>> seconds are only announced six months in advance.
>>
>>
>>
>> This means that, in a quest to develop a system with absolute precision
>> and certainty about which certificate validity periods are legal we have
>> instead created a system where a validly issued certificate can have an
>> invalid lifetime due to a leap second that was announced after it was
>> issued.  And tools like zlint would have to periodically download the
>> latest version of the official leap second list in order to accurately make
>> difference calculations.  And the tools would have to take into account
>> whether the leap second was announced yet or not at the time of issuance …
>> ugh.
>>
>>
>>
>> So, yeah.  Let’s ignore leap seconds.
>>
>>
>>
>> -Tim
>>
>>
>>
>> *From:* Wayne Thayer <wthayer at gmail.com>
>> *Sent:* Friday, November 19, 2021 12:54 PM
>> *To:* Aaron Gable <aaron at letsencrypt.org>; CA/B Forum Server Certificate
>> WG Public Discussion List <servercert-wg at cabforum.org>
>> *Cc:* Tim Hollebeek <tim.hollebeek at digicert.com>
>> *Subject:* Re: [Servercert-wg] Discussion Period Begins: SC-52: Specify
>> CRL Validity Intervals in Seconds
>>
>>
>>
>> Thank you Aaron. I went ahead and created a pull request since I
>> originally drafted the ballot:
>> https://github.com/cabforum/servercert/pull/327
>>
>>
>>
>> I will defer to Tim as the official proposer of the ballot, but I support
>> making these proposed changes and would be happy to add them to the PR.
>>
>>
>>
>> - Wayne
>>
>>
>>
>> On Fri, Nov 19, 2021 at 10:19 AM Aaron Gable via Servercert-wg <
>> servercert-wg at cabforum.org> wrote:
>>
>> Absolutely; I have three proposals below. I don't expect the fixed-width
>> formatting and diff coloring to come through on servercert-wg, but
>> hopefully it'll make it to your personal inbox intact.
>>
>>
>>
>> Personally, I'd prefer that all time periods be computed ignoring leap
>> seconds. Counting leap seconds, and therefore having the time between two
>> timestamps which are ostensibly represent an interval of 24 hours (e.g.
>> 2021-11-01 12:34:56 and 2021-11-02 12:34:55) *sometimes* represent more
>> than 24 hours feels like a "gotcha!". It does encourage CAs to not push
>> right up against the specified limits, which is a good thing, but it feels
>> to me like it would be preferable to incentivise that in a way that doesn't
>> rely on random fluctuations in the Earth's rotational period. (Also, thanks
>> to global climate disaster, the melting ice caps have contributed to the
>> last five years having some of the fastest Earth rotation on record, and
>> the IERS is currently considering *negative* leap seconds.)
>>
>>
>>
>> So my personal favorite diff to include in this ballot would be:
>>
>>
>>
>> ```
>>
>> diff --git a/docs/BR.md b/docs/BR.md
>> index 912cbf1..b0220dd 100644
>> --- a/docs/BR.md
>> +++ b/docs/BR.md
>> @@ -573,7 +573,7 @@ The key words "MUST", "MUST NOT", "REQUIRED",
>> "SHALL", "SHALL NOT", "SHOULD", "S
>>
>>  By convention, this document omits time and timezones when listing
>> effective requirements such as dates. Except when explicitly specified, the
>> associated time with a date shall be 00:00:00 UTC.
>>
>> -**Effective 2022-06-01:** For purposes of computing differences, a
>> difference of 3,600 seconds shall be equal to one hour, and a difference of
>> 86,400 seconds shall be equal to one day. Any amount of time greater than
>> this, including fractional seconds and/or leap seconds, shall represent an
>> additional unit of measure, such as an additional hour or additional day.
>> +**Effective 2022-06-01:** For purposes of computing differences, a
>> difference of 3,600 seconds shall be equal to one hour, and a difference of
>> 86,400 seconds shall be equal to one day, ignoring leap seconds. Any amount
>> of time greater than this, including fractional seconds, shall represent an
>> additional unit of measure, such as an additional hour or additional day.
>>
>>  # 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
>>
>> @@ -1324,7 +1324,7 @@ defined by RFC6960.
>>
>>  OCSP responders operated by the CA SHALL support the HTTP GET method, as
>> described in RFC 6960 and/or RFC 5019.
>>
>> -For the purpose of computing an OCSP Validity Interval, a difference of
>> 3,600 seconds shall be equal to one hour, and a difference of 86,400
>> seconds shall be equal to one day, ignoring leap-seconds.
>> +As stated in [Section 1.6.4](#164-conventions), for the purpose of
>> computing an OCSP Validity Interval, an hour is measured as 3,600 seconds
>> and a day is measured as 86,400 seconds, ignoring leap seconds.
>>
>>  For the status of Subscriber Certificates:
>>
>> @@ -1748,7 +1748,9 @@ Subscriber Certificates issued on or after 1
>> September 2020 SHOULD NOT have a Va
>>  Subscriber Certificates issued after 1 March 2018, but prior to 1
>> September 2020, MUST NOT have a Validity Period greater than 825 days.
>>  Subscriber Certificates issued after 1 July 2016 but prior to 1 March
>> 2018 MUST NOT have a Validity Period greater than 39 months.
>>
>> -As stated in [Section 1.6.4](#164-conventions), a day is measured as
>> 86,400 seconds. Any amount of time greater than this, including fractional
>> seconds and/or leap seconds, shall represent an additional day. For this
>> reason, Subscriber Certificates SHOULD NOT be issued for the maximum
>> permissible time by default, in order to account for such adjustments.
>> +**For Certificates issued prior to 2022-06-01:** For the purpose of
>> calculations, a day is measured as 86,400 seconds. Any amount of time
>> greater than this, including fractional seconds and/or leap seconds, shall
>> represent an additional day. For this reason, Subscriber Certificates
>> SHOULD NOT be issued for the maximum permissible time by default, in order
>> to account for such adjustments.
>> +
>> +**For Certificates issued on or after 2022-06-01:** As stated in
>> [Section 1.6.4](#164-conventions), a day is measured as 86,400 seconds,
>> ignoring leap seconds. Any amount of time greater than this, including
>> fractional seconds, shall represent an additional day. For this reason,
>> Subscriber Certificates SHOULD NOT be issued for the maximum permissible
>> time by default.
>>
>>  ## 6.4 Activation data
>>
>> ```
>>
>>
>>
>> But I recognize that such a change is perhaps larger than this ballot
>> wants to tackle, and would bring in more discussion. So for taking things
>> the other way, I would propose the following simple diff, which changes how
>> OCSP validity intervals are calculated (to include leap seconds, instead of
>> ignoring them) as of the effective date of the ballot:
>>
>>
>>
>> ```
>> diff --git a/docs/BR.md b/docs/BR.md
>> index 912cbf1..b90eb98 100644
>> --- a/docs/BR.md
>> +++ b/docs/BR.md
>> @@ -1324,7 +1324,7 @@ defined by RFC6960.
>>
>>  OCSP responders operated by the CA SHALL support the HTTP GET method, as
>> described in RFC 6960 and/or RFC 5019.
>>
>> -For the purpose of computing an OCSP Validity Interval, a difference of
>> 3,600 seconds shall be equal to one hour, and a difference of 86,400
>> seconds shall be equal to one day, ignoring leap-seconds.
>> +**For OCSP responses issued prior to 2022-06-01:** For the purpose of
>> computing an OCSP Validity Interval, a difference of 3,600 seconds shall be
>> equal to one hour, and a difference of 86,400 seconds shall be equal to one
>> day, ignoring leap-seconds.
>>
>>  For the status of Subscriber Certificates:
>>
>> ```
>>
>>
>>
>> If folks don't think that is explicit enough, then I would borrow the
>> language from the section on Certificate Profiles to make the point clear:
>>
>>
>>
>> ```
>>
>> diff --git a/docs/BR.md b/docs/BR.md
>> index 912cbf1..b2071ac 100644
>> --- a/docs/BR.md
>> +++ b/docs/BR.md
>> @@ -1324,7 +1324,9 @@ defined by RFC6960.
>>
>>  OCSP responders operated by the CA SHALL support the HTTP GET method, as
>> described in RFC 6960 and/or RFC 5019.
>>
>> -For the purpose of computing an OCSP Validity Interval, a difference of
>> 3,600 seconds shall be equal to one hour, and a difference of 86,400
>> seconds shall be equal to one day, ignoring leap-seconds.
>> +**For OCSP responses issued prior to 2022-06-01:** For the purpose of
>> computing an OCSP Validity Interval, a difference of 3,600 seconds shall be
>> equal to one hour, and a difference of 86,400 seconds shall be equal to one
>> day, ignoring leap-seconds.
>> +
>> +**For OCSP responses issued on or after 2022-06-01:** As stated in
>> [Section 1.6.4](#164-conventions), an hour is measured as 3,600 seconds,
>> and a day is measured as 86,400 seconds. Any amount of time greater than
>> this, including fractional seconds and/or leap seconds, shall represent an
>> additional day. For this reason, OCSP responses SHOULD NOT be issued for
>> the maximum permissible time by default, in order to account for such
>> adjustments.
>>
>>  For the status of Subscriber Certificates:
>>
>> ```
>>
>>
>>
>> It doesn't appear that this ballot is represented by a PR, just a diff
>> currently, otherwise I'd use GitHub's "suggest an edit" feature directly on
>> that PR.
>>
>>
>>
>> Aaron
>>
>>
>>
>> On Fri, Nov 19, 2021 at 7:44 AM Tim Hollebeek <tim.hollebeek at digicert.com>
>> wrote:
>>
>> Hey Aaron,
>>
>>
>>
>> Thank you very much for this detailed analysis.  As I mentioned on
>> yesterday’s validation call, this is exactly the sort of risk I’m concerned
>> about with this ballot.
>>
>>
>>
>> Thanks for catching the leap second issue.  I think it’s important that
>> we resolve that and have a consistent way of converting days -> seconds
>> throughout the document.
>>
>>
>>
>> If you would like to take a whack at proposed text to fix it, I’m
>> listening and interested.
>>
>>
>>
>> -Tim
>>
>>
>>
>> *From:* Aaron Gable <aaron at letsencrypt.org>
>> *Sent:* Thursday, November 18, 2021 3:52 PM
>> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>; CA/B Forum Server
>> Certificate WG Public Discussion List <servercert-wg at cabforum.org>
>> *Subject:* Re: [Servercert-wg] Discussion Period Begins: SC-52: Specify
>> CRL Validity Intervals in Seconds
>>
>>
>>
>> Throughout the BRs, there are many different kinds of time intervals:
>> - how long a cert is valid
>> - how long a CRL is valid
>> - how long an OCSP response is valid
>> - how long a validation document can be used
>> - how long a random value can be used
>> - how long a CA has to perform a revocation
>> - how quickly CAs must provide their first audit and disclose CPS changes
>> in CCADB
>>
>> Although the purpose of this ballot is focused on CRLs, I think there are
>> two things we need to notice about it:
>>
>> First, by moving the declaration of how differences are counted into
>> Section 1.6.4 Conventions, this method of computing time differences *does*
>> apply to validation documents, random values, and all other time intervals.
>> CAs should be aware that these lifetimes will now be measured to the
>> precision of seconds, and should take care to ensure that they are not
>> (e.g.) reusing validation documents right up against the limit.
>>
>> This does introduce a slight issue, in that some of these other intervals
>> express some of their timetables in terms of days (now very precise) and
>> some of their timetables in months (still imprecise). But that can be
>> solved in a follow-up ballot.
>>
>> Second, although this ballot does not *change* how OCSP validity
>> intervals are calculated, I believe that it does increase the chances of
>> confusion on how to do so. Calling out three lines from the ballot diff:
>>
>> Section 1.6.1 Definitions:
>> > **Validity Interval**: For CRLs and OCSP responses, the difference in
>> time between the thisUpdate and nextUpdate field, inclusive.
>>
>> Section 1.6.4 Conventions:
>> > **Effective 2022-06-01:** For purposes of computing differences, a
>> difference of 3,600 seconds shall be equal to one hour, and a difference of
>> 86,400 seconds shall be equal to one day. Any amount of time greater than
>> this, including fractional seconds and/or leap seconds, shall represent an
>> additional unit of measure, such as an additional hour or additional day.
>>
>> Section 4.9.10 On-line revocation checking requirements
>> > For the purpose of computing an OCSP Validity Interval, a difference of
>> 3,600 seconds shall be equal to one hour, and a difference of 86,400
>> seconds shall be equal to one day, ignoring leap-seconds.
>>
>> The first two quotes appear to combine to say that, for OCSP responses,
>> the validity interval shall be the difference in time between the
>> thisUpdate and the nextUpdate, and that any amount of time greater than
>> that (such as leap seconds) shall represent an additional day of validity
>> interval. However, this definition is then superseded by 4.9.10, which says
>> that OCSP validity intervals ignore leap seconds.
>>
>> I believe that the BRs should unify on either always including leap
>> seconds (and that therefore CAs should be careful to not run right up
>> against the limits, in case a leap second is inserted), or on always
>> ignoring leap seconds. In particular, I propose the following text be
>> included in section 4.9.10 in this ballot:
>> > **Effective prior to 2022-06-01:** For the purpose of computing an OCSP
>> Validity Interval, a difference...
>>
>> If folks believe that that change should not be included in this ballot,
>> then I think that this ballot should not attempt to unify the calculation
>> of the validity interval for OCSP and CRLs, as doing so leads to this
>> confusion.
>>
>> Aaron
>>
>>
>>
>> On Thu, Nov 18, 2021 at 7:43 AM Tim Hollebeek via Servercert-wg <
>> servercert-wg at cabforum.org> wrote:
>>
>> Ballot SC-52: Specify CRL Validity Intervals in Seconds
>>
>> Purpose of Ballot: Similar to Ballot SC-31 which modified the
>> specification of
>>
>> OCSP validity periods to be in seconds, this ballot modifies the
>> specification
>>
>> of CRL validity periods to be in seconds to avoid confusion about exactly
>> which
>>
>> periods are valid and which are not.  The ballot also specifies that
>> other time
>>
>> periods should be handled the same way, which has broader impacts
>> throughout
>>
>> the document.
>>
>>
>>
>> The following motion has been proposed by Tim Hollebeek of DigiCert and
>> endorsed
>>
>> by Trevoli Ponds-White of Amazon and Kati Davids of GoDaddy.
>>
>>
>>
>> ---MOTION BEGINS---
>>
>>
>>
>> This ballot modifies the “Baseline Requirements for the Issuance and
>> Management
>>
>> of Publicly-Trusted Certificates” (“Baseline Requirements”), based on
>> Version 1.8.0:
>>
>>
>>
>> MODIFY the Baseline Requirements as specified in the following Redline:
>>
>>
>>
>>
>> https://github.com/cabforum/servercert/compare/cda0f92ee70121fd5d692685b97ebb6669c74fb7...0c265a673b10c460264a721214b902484c0d1c1f
>>
>>
>>
>> ---MOTION ENDS---
>>
>>
>>
>> This ballot proposes a Final Maintenance Guideline.
>>
>>
>>
>> The procedure for approval of this ballot is as follows:
>>
>>
>>
>> Discussion (7+ days)
>>
>> Start Time: November 18, 2021 10:30am Eastern
>>
>> End Time: No earlier than November 25, 2021 10:30 am Eastern
>>
>> Vote for approval (7 days)
>>
>> Start Time: TBD
>>
>> End Time: TBD
>>
>> _______________________________________________
>> Servercert-wg mailing list
>> Servercert-wg at cabforum.org
>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>
>> _______________________________________________
>> Servercert-wg mailing list
>> Servercert-wg at cabforum.org
>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20211122/49241ac0/attachment-0001.html>