[cabf_validation] CRL Validity Interval Ballot

[Dimitris Zacharopoulos (HARICA)]

On 13/10/2021 4:21 μ.μ., Ryan Sleevi wrote:
>
>
> On Wed, Oct 13, 2021 at 3:08 AM Dimitris Zacharopoulos (HARICA) via 
> Validation <validation at cabforum.org <mailto:validation at cabforum.org>> 
> wrote:
>
>     We also noted that there are already *two places* where we
>     "define" the duration of a day:
>
>       * Section 4.9.10: /"//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."/
>       * Section 6.3.2: /"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."/
>
>     Instead of creating another instance of the same definition in
>     4.9.7, it might be better to use the already defined term
>     "Validity Period" and add the following sentence /"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."/
>
>
> The defined term is inherited from RFC 5280, and specific to 
> certificates. For example, you cannot substitute the definition of 
> "validity period" into 3.2.2.4.2 for the Random Value use. The use of 
> the term in 4.9.10 is a bug - it should be "validity interval", not 
> "validity period" (an issue introduced during the drafting)
>
> Proposing something to 1.6.4 might be clearer, but that would only 
> cover differences of dates; whether or not to factor in inclusiveness 
> depends on whether it's part of an abstract value (i.e. a 
> UTCTime/GeneralizedTime within a certificate).
>
>     It would be even clearer if in 4.9.7 and 4.9.10 we added a
>     statement about the value of the nextUpdate field as being "i.e.
>     /nextUpdate ≤ thisUpdate + 365 * 86400s/" for the subCAs and "i.e.
>     /nextUpdate ≤ thisUpdate + 10 * 86400s/" for Subscriber Certificates.
>
>
> As a smaller note, the choice (of months being 30 days, and of years 
> being 365 days) is inconsistent with the root program definitions, 
> which have taken the approach of specifying the upper-bounds in ways 
> to avoid ambiguity. For example, the longest possible interpretation 
> of 3 months is "31 + 31 + 30" - or 92 days. The longest interpretation 
> for "13 months" is 366 (leap year) + 31 - hence, 397 days. Note that 
> then a further day was added - to ensure that if a CA set something 
> for 397 days (or 365 days), there was no chance of them running afoul 
> of the requirement, even if they failed to account for leap seconds 
> and fractional seconds. So 3 months would be 93 days. 13 months is 398 
> days. One month is 32 days.
>
> Does this mean CAs should use those absolute maximums? Of course not. 
> It simply allows them to be calendrically aligned without need for 
> further computation.

I assume that the majority of Members would be in favor of making a 
requirement unambiguous in the BRs that can be measured consistently 
across the board. I recommend we use this opportunity to fix the 
existing bug in 4.9.10 and set an reasonable effective date for CAs to 
update their validity period configurations for CRLs and OCSP measured 
in days instead of months. This may result in stricter requirements than 
the existing Root program requirements (would that be a first???) but 
this doesn't necessarily mean it is problematic.

Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20211013/164695d0/attachment.html>