[cabf_validation] CRL Validity Interval Ballot

Thu Nov 11 14:00:25 UTC 2021

To be clear, my suggestion was primarily motivated by a desire for the
language to be unified between the two sections; the increased ease of
removing that language later was a nice side-effect. But it's ultimately
such a minor quibble about the text of this ballot that I don't have a
vested interest one way or the other.

On Wed, Nov 10, 2021 at 3:31 PM Wayne Thayer <wthayer at gmail.com> wrote:

> I'm not strongly opposed to either of these proposed changes, but if the
> goal is to remember to clean up line 1319 after this is effective, then I
> don't think Aaron's suggestion is nearly as helpful as simply opening an
> issue against the repo to record this as a future task. I'm somewhat more
> concerned about tying TIm's suggestion to this particular ballot rather
> than having a general discussion about the approach of annotating the doc.
> I would ask the proposer to move forward with the ballot in its current
> state in the interest of giving CAs plenty of time to review and adapt to
> the broader change that becomes effective on June 1st.
>
> Thanks,
>
> Wayne
>
> On Tue, Nov 9, 2021 at 10:36 AM Tim Hollebeek <tim.hollebeek at digicert.com>
> wrote:
>
>> Would it make sense to put an invisible markdown comment next to these
>> lines that should be removed in a future cleanup?
>>
>>
>>
>> []: # ‘Cleanup ballot – after 2025-01-01’
>>
>> For certificates issued before January 1, 2025, the Certificate Subject
>> SHALL be an Apple.  Effective January 1, 2025, the Certificate Subject
>> SHALL be an orange.
>>
>>
>>
>> This would make it easier to find them when cleanup ballots are being
>> prepared.
>>
>>
>>
>> -Tim
>>
>>
>>
>> *From:* Validation <validation-bounces at cabforum.org> *On Behalf Of *Aaron
>> Gable via Validation
>> *Sent:* Tuesday, November 9, 2021 11:48 AM
>> *To:* Wayne Thayer <wthayer at gmail.com>; CABforum3 <
>> validation at cabforum.org>
>> *Subject:* Re: [cabf_validation] CRL Validity Interval Ballot
>>
>>
>>
>> I would suggest that line 1327 (previously line 1319) be updated in the
>> same fashion as line 1751 (previously line 1748):
>>
>> "As stated in [Section 1.6.4](#164-conventions), a difference of 3,600
>> seconds shall..."
>>
>>
>>
>> This clearly tags both of those lines as able to be removed in a future
>> cleanup.
>>
>>
>>
>> On Thu, Nov 4, 2021 at 9:26 AM Wayne Thayer via Validation <
>> validation at cabforum.org> wrote:
>>
>> 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
>>
>> _______________________________________________
>> 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/20211111/f437cd3c/attachment-0001.html>