<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    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".<br>
    <br>
    Dimitris.<br>
    <br>
    <div class="moz-cite-prefix">On 14/10/2021 7:34 μ.μ., Wayne Thayer
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAPh8bk_qD8cnUj+BYeh5qMtzb7qtsXTRf+KFzwe7Zhh44NF=Nw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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"
            moz-do-not-send="true">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"
                  moz-do-not-send="true">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" moz-do-not-send="true">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>
    </blockquote>
    <br>
  </body>
</html>