[cabf_validation] CRL Validity Interval Ballot

[Ryan Sleevi]

On Wed, Oct 13, 2021 at 10:05 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

> 4.9.7 and 4.9.10 have a nextUpdate requirement for Root CRLs and OCSP
> responses, and this is set for 12 months. Do we want the same level of
> "accuracy" as the CRL/OCSP responses of Subordinate CAs? If we do not, then
> we can focus on language about just the CRLs/OCSP responses issued by
> "online" CAs, as Wayne has already done at the proposed ballot and there is
> no need to make further changes to the BRs.
>
> If I understand your position, you believe we should be specific (to the
> second) only for specific requirements, such as those linked to RFC 5280
> (validity of a certificate, validity period of a CRL/OCSP response) and not
> the other cases (related to request tokens, audit reports, etc). Is that
> accurate?
>

Got it. Definite misunderstanding :)

To try to rephrase:

   - Defining a day to be 86,400 seconds (with caveats) is appropriate for
   Section 1.6.4 if the desire is to make this ballot a broader "date
   interval" cleanup rather than just the CRL cleanup
   - This convention cannot address the "inclusive" aspect; that will need
   to remain appropriate for ASN.1 types (certificates, CRLs, OCSP)
   - The term "validity period" refers to certificates, and comes from
   X.509/RFC 5280. The term "validity interval" is a term we introduced for
   OCSP, because CRLs and OCSP responses don't necessarily have 'validity
   periods' (intervals, freshness, etc are all concepts used to refer to them)
   - Taken together with the previous bullet: This means there still needs
      to be definitions specific to those, and within the specific sections
      (long-term, this would be the relevant profiles for
certificates, CRLs, and
      OCSP, rather than the current distributed locations)
   - Procedural controls - request tokens, audit reports, etc - still make
   sense to define in days
      - However, the choice of period - 90 days vs 93 days, 397 days vs 398
      days, 31 days vs 32 days - were intentionally selected to *allow* CAs
      to have a fixed calendrical schedule, without risk of violation.
      - For example, if you have a 30 day period, then over a year, you
      will have shifted 5 to 6 days. You won't be able to, for example, "do
      something on the first of every month"
      - The "extra day" is to make sure that if you do it at 9am on the 1st
      of the month prior, you (hopefully unambiguously) have until midnight of
      the 1st of the current month, without running afoul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20211013/ec34f52a/attachment.html>