[cabf_validation] CRL Validity Interval Ballot

[Wayne Thayer]

Thank you Ryan! I merged in your changes:
https://github.com/cabforum/servercert/compare/main...wthayer:ballot-SC52

On Fri, Oct 15, 2021 at 2:12 PM Ryan Sleevi <sleevi at google.com> wrote:

> Suggested edits in https://github.com/wthayer/servercert/pull/12/files as
> PR to your branch
>
> On Fri, Oct 15, 2021 at 4:59 PM Wayne Thayer <wthayer at gmail.com> wrote:
>
>> How does this look?
>>
>> https://github.com/cabforum/servercert/compare/main...wthayer:ballot-SC52
>>
>> Thanks,
>>
>> Wayne
>>
>> On Thu, Oct 14, 2021 at 11:50 AM Dimitris Zacharopoulos (HARICA) <
>> dzacharo at harica.gr> wrote:
>>
>>> 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> wrote:
>>>
>>>>
>>>>
>>>> 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/20211018/3cdc86b1/attachment.html>