[cabf_validation] CRL Validity Interval Ballot

[Ryan Sleevi]

On Wed, Oct 13, 2021 at 3:08 AM Dimitris Zacharopoulos (HARICA) via
Validation <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20211013/10b2c835/attachment.html>