[cabf_validation] CRL Validity Interval Ballot

[Ryan Sleevi]

On Wed, Oct 13, 2021 at 10:57 AM Dimitris Zacharopoulos (HARICA) <
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> 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
>
>
>
> 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/20211013/c85dc116/attachment-0001.html>