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

Fri Nov 19 21:20:36 UTC 2021

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/20211119/9fef72e2/attachment-0001.html>