<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 13, 2021 at 10:05 AM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">dzacharo@harica.gr</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    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. <br>
    <br>
    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?<br></div></blockquote><div><br></div><div>Got it. Definite misunderstanding :)</div><div><br></div><div>To try to rephrase:</div><div><ul><li>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</li><li>This convention cannot address the "inclusive" aspect; that will need to remain appropriate for ASN.1 types (certificates, CRLs, OCSP)<br></li><li>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) <br></li><ul><li>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)</li></ul><li>Procedural controls - request tokens, audit reports, etc - still make sense to define in days</li><ul><li>However, the choice of period - 90 days vs 93 days, 397 days vs 398 days, 31 days vs 32 days - were intentionally selected to <i>allow</i> CAs to have a fixed calendrical schedule, without risk of violation.</li><li>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"</li><li>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</li></ul></ul><div><br></div></div></div></div>