<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 13/10/2021 4:21 μ.μ., Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvYuigEaZdRnKq=NnvDo7KLAQY02HtGmVd6LWLbx3VzefA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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>
</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>
</blockquote>
<br>
I assume that the majority of Members would be in favor of making a
requirement unambiguous in the BRs that can be measured consistently
across the board. I recommend we use this opportunity to fix the
existing bug in 4.9.10 and set an reasonable effective date for CAs
to update their validity period configurations for CRLs and OCSP
measured in days instead of months. This may result in stricter
requirements than the existing Root program requirements (would that
be a first???) but this doesn't necessarily mean it is problematic.<br>
<br>
Dimitris.<br>
</body>
</html>