[cabf_validation] CRL Validity Interval Ballot

Thu Nov 4 16:25:43 UTC 2021

On today's Validation SC call, a concern was raised about the scope and
timing of the addition to section 1.6.4 Conventions that describes the
method to be used for computing time differences across the entire
document. Since this has effects well beyond CRLs - for example, the
lifetime of a random value - it was agreed that it should have a future
effective date that allows time for CAs to become compliant. I've update
the proposal to reflect the conclusion of this discussion:

https://github.com/cabforum/servercert/compare/main...wthayer:ballot-SC52

Please have a look and reply with any problems that you find with the new
language.

Note that line 1319 will become redundant on 1-June 2022 and should be
removed in a future cleanup ballot.

Thanks,

Wayne

On Sun, Oct 31, 2021 at 1:08 PM Wayne Thayer via Validation <
validation at cabforum.org> wrote:

> Good point Tim. I just updated the branch to state "at least every 367
> days; and" to match section 4.9.10.
>
> On Fri, Oct 29, 2021 at 1:23 PM Tim Hollebeek <tim.hollebeek at digicert.com>
> wrote:
>
>>
>> Line 1301: “i. once every 367 days; and”
>>
>>
>>
>> I think that provision needs an “at least” as well.  I don’t think we
>> expect CAs to issue CRLs once every 367 days.
>>
>>
>>
>> -Tim
>>
>>
>>
>> *From:* Wayne Thayer <wthayer at gmail.com>
>> *Sent:* Monday, October 18, 2021 8:29 PM
>> *To:* Ryan Sleevi <sleevi at google.com>
>> *Cc:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>; CABforum3 <
>> validation at cabforum.org>; Tim Hollebeek <tim.hollebeek at digicert.com>
>> *Subject:* Re: [cabf_validation] CRL Validity Interval Ballot
>>
>>
>>
>> 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.
>>
>>
>>
>> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20211104/a5e8cbf6/attachment.html>