<div dir="ltr"><div>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?</div><div><br></div><div>Shall I also create a definition for 'validity interval' and make it applicable to CRLs and OCSP responses?</div><div><br></div><div>Thanks,</div><div><br></div><div>Wayne<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 13, 2021 at 8:08 AM Ryan Sleevi <<a href="mailto:sleevi@google.com">sleevi@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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:57 AM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr" target="_blank">dzacharo@harica.gr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <br>
    <br>
    <div>On 13/10/2021 5:17 μ.μ., Ryan Sleevi
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <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" target="_blank">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>
    </blockquote>
    <br>
    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?<br></div></blockquote><div><br></div><div>Days was/is the suggestion. Months being 30 days or 31 days has the calendrical drift issue. So 367 days = 1 year/12 months. </div></div></div>
</blockquote></div>