[cabf_validation] CRL Validity Interval Ballot

[Dimitris Zacharopoulos (HARICA)]

On 13/10/2021 5:17 μ.μ., Ryan Sleevi wrote:
>
>
> On Wed, Oct 13, 2021 at 10:05 AM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto: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)
>       o 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
>       o 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.
>       o 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"
>       o 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
>
>

Got it. Do you have any guidance or preference for the offline CA 
CRLs/OCSP responses? Should that continue to be described in months or 
move into something more specific?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20211013/753366d5/attachment.html>