<div dir="ltr"><div>How does this look?</div><div><br></div><div><a href="https://github.com/cabforum/servercert/compare/main...wthayer:ballot-SC52">https://github.com/cabforum/servercert/compare/main...wthayer:ballot-SC52</a></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 Thu, Oct 14, 2021 at 11:50 AM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">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>
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>On 14/10/2021 7:34 μ.μ., Wayne Thayer
wrote:<br>
</div>
<blockquote type="cite">
<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" target="_blank">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>
</blockquote>
<br>
</div>
</blockquote></div>