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

Fri Nov 19 17:54:22 UTC 2021

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/20211119/84995e88/attachment-0001.html>