[cabf_validation] CRL Validity Interval Ballot

[Dimitris Zacharopoulos (HARICA)]

That's my understanding too. If we are to create the "validity interval" 
definition, we must be clear that it is only applicable to CRLs and OCSP 
responses and that might be a bit challenging. Also change the term in 
4.9.10 "validity interval" instead of "validity period".

Dimitris.

On 14/10/2021 7:34 μ.μ., Wayne Thayer wrote:
> My conclusion from this discussion is that the ballot should be 
> updated to specify the validity interval of root CRLs and OCSP 
> responses in days instead of months, with 397 days a SHOULD and 398 
> days a MUST. Ryan and Dimitris, is that correct?
>
> Shall I also create a definition for 'validity interval' and make it 
> applicable to CRLs and OCSP responses?
>
> Thanks,
>
> Wayne
>
> On Wed, Oct 13, 2021 at 8:08 AM Ryan Sleevi <sleevi at google.com 
> <mailto:sleevi at google.com>> wrote:
>
>
>
>     On Wed, Oct 13, 2021 at 10:57 AM Dimitris Zacharopoulos (HARICA)
>     <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>
>
>
>         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?
>
>
>     Days was/is the suggestion. Months being 30 days or 31 days has
>     the calendrical drift issue. So 367 days = 1 year/12 months.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20211014/f0b9eac6/attachment-0001.html>