<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 3:08 AM Dimitris Zacharopoulos (HARICA) via Validation <<a href="mailto:validation@cabforum.org">validation@cabforum.org</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>
    We also noted that there are already <b>two places</b> where we
    "define" the duration of a day:<br>
    <ul>
      <li>Section 4.9.10: <i>"</i><i>For purposes of computing
          differences, a difference of 3,600 seconds shall be equal to
          one hour, and a difference of 86,400 seconds shall be equal to
          one day, ignoring leap-seconds."</i></li>
      <li>Section 6.3.2: <i>"For the purpose of calculations, a day is
          measured as 86,400 seconds. Any amount of time greater than
          this, including fractional seconds and/or leap seconds, shall
          represent an additional day. For this reason, Subscriber
          Certificates SHOULD NOT be issued for the maximum permissible
          time by default, in order to account for such adjustments."</i><br>
        <i></i></li>
    </ul>
    Instead of creating another instance of the same definition in
    4.9.7, it might be better to use the already defined term "Validity
    Period" and add the following sentence <i>"For purposes of
      computing differences, a difference of 3,600 seconds shall be
      equal to one hour, and a difference of 86,400 seconds shall be
      equal to one day, ignoring leap-seconds."</i></div></blockquote><div><br></div><div>The defined term is inherited from RFC 5280, and specific to certificates. For example, you cannot substitute the definition of "validity period" into 3.2.2.4.2 for the Random Value use. The use of the term in 4.9.10 is a bug - it should be "validity interval", not "validity period" (an issue introduced during the drafting)</div><div><br></div><div>Proposing something to 1.6.4 might be clearer, but that would only cover differences of dates; whether or not to factor in inclusiveness depends on whether it's part of an abstract value (i.e. a UTCTime/GeneralizedTime within a certificate).</div><div> <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>
    It would be even clearer if in 4.9.7 and 4.9.10 we added a statement
    about the value of the nextUpdate field as being "i.e. <i>nextUpdate
      ≤ thisUpdate + 365 * 86400s</i>" for the subCAs and "i.e. <i>nextUpdate
      ≤ thisUpdate + 10 * 86400s</i>" for Subscriber Certificates.<br></div></blockquote><div><br></div><div>As a smaller note, the choice (of months being 30 days, and of years being 365 days) is inconsistent with the root program definitions, which have taken the approach of specifying the upper-bounds in ways to avoid ambiguity. For example, the longest possible interpretation of 3 months is "31 + 31 + 30" - or 92 days. The longest interpretation for "13 months" is 366 (leap year) + 31 - hence, 397 days. Note that then a further day was added - to ensure that if a CA set something for 397 days (or 365 days), there was no chance of them running afoul of the requirement, even if they failed to account for leap seconds and fractional seconds. So 3 months would be 93 days. 13 months is 398 days. One month is 32 days.</div><div><br></div><div>Does this mean CAs should use those absolute maximums? Of course not. It simply allows them to be calendrically aligned without need for further computation.</div></div></div>