<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
Thank you for the attempt to clarify the nextUpdate values for CRLs
to match the language from section 4.9.10 regarding the OCSP
response validity.<br>
<br>
After some review, and since it appears there is consensus to move
to the "1 sec" accuracy in various fields, HARICA believe we should
also define that 1 month is equal to 30 days. We already have
language to specify that 1 day is equal to 86400 seconds but some
interpret 12 months to be 365 days, others consider 360 days as
being more accurate, etc.<br>
<br>
It would be even better to specify the <i>nextUpdate </i>for
subCAs in <i>days</i> instead of <i>months</i>. There are only 4
areas where a requirement is specified in months:<br>
<ul>
<li>Section 4.9.7 (as already mentioned)</li>
<li>Section 4.9.10 (as already mentioned)<br>
</li>
<li>Section 8.1 Frequency or circumstances of assessment: <i>"</i><i>The
point-in-time readiness assessment SHALL be completed no
earlier than twelve (12) months prior to issuing
Publicly-Trusted Certificates and..."</i> </li>
<li>Section 8.6 Communication of results: "<i>The CA MUST make its
Audit Report publicly available no later than three months
after the end of the audit period. In the event of a delay
greater than three months, the CA SHALL provide an explanatory
letter signed by the Qualified Auditor."</i></li>
</ul>
Thus, if we converted these to days, we would not need to define
that a month is equal to 30 days.<br>
<br>
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><br>
<br>
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>
<br>
Thoughts?<br>
<br>
<br>
Dimitris.<br>
<br>
<div class="moz-cite-prefix">On 7/10/2021 8:34 μ.μ., Wayne Thayer
via Validation wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0100017c5bd1ef54-b0d7864c-87a3-46cc-841a-ef0201d08904-000000@email.amazonses.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Here is a draft of the ballot that we discussed on today's
call to clarify the maximum permitted validity interval of a
CRL in the BRs. I've gone ahead and reserved a ballot number
and inserted Tim as the proposer and Trev and Kati as
endorsers.<br>
</div>
<div><font size="4"><b><br>
</b></font></div>
<div><font size="4"><b>BALLOT SC52: Specify Validity Interval of
CRLs</b></font><br>
</div>
<div>
<h2 class="gmail-sectionedit1 gmail-page-header"
id="gmail-purpose_of_ballot"><font size="4">PURPOSE OF
BALLOT</font></h2>
<div class="gmail-level2">
<p>
Ballot SC31 included a clarification of the maximum
allowed validity interval for OCSP responses in section
4.9.10 of the Baseline Requirements. A similar ambiguity
has been identified in section 4.9.7 for the validity
interval of CRLs. This ballot better specifies the maximum
validity interval for CRLs issues after 1-Feb-2022 by
applying the language from section 4.9.10 to CRLs.
</p>
<p>
The following motion has been proposed by Tim Hollebeek of
DigiCert and endorsed by Trevoli Ponds-White of Amazon and
Kati Davids of GoDaddy.
</p>
</div>
<div class="gmail-secedit editbutton_section editbutton_1">
<form class="gmail-button gmail-btn_secedit
gmail-form-inline" method="post"
action="/scwg/sc48-domain_name_and_ip_address_encoding"></form>
</div>
<h2 class="gmail-sectionedit2 gmail-page-header"
id="gmail-motion_begins"><font size="4">MOTION BEGINS</font></h2>
<div class="gmail-level2">
<p>
This ballot modifies the “Baseline Requirements for the
Issuance and Management of Publicly-Trusted Certificates”
(“Baseline Requirements”), based on Version 1.8.0:<br>
MODIFY the Baseline Requirements as specified in the
following Redline:<br>
<a
href="https://github.com/cabforum/servercert/compare/main...wthayer:ballot-SC52"
moz-do-not-send="true">https://github.com/cabforum/servercert/compare/main...wthayer:ballot-SC52</a>
<span style="color:rgb(241,194,50)">(NOTE: THIS LINK NEEDS
TO BE UPDATED TO REFERENCE SPECIFIC COMMITS IN THE FINAL
BALLOT)
</span></p>
</div>
<div class="gmail-secedit editbutton_section editbutton_2">
<form class="gmail-button gmail-btn_secedit
gmail-form-inline" method="post"
action="/scwg/sc48-domain_name_and_ip_address_encoding"></form>
</div>
<h2 class="gmail-sectionedit3 gmail-page-header"
id="gmail-motion_ends"><font size="4">MOTION ENDS</font></h2>
<div class="gmail-level2">
<p>
This ballot proposes a Final Maintenance Guideline.
The procedure for approval of this ballot is as follows:
</p>
</div>
<div class="gmail-secedit editbutton_section editbutton_3">
<form class="gmail-button gmail-btn_secedit
gmail-form-inline" method="post"
action="/scwg/sc48-domain_name_and_ip_address_encoding"></form>
</div>
<h3 class="gmail-sectionedit4" id="gmail-discussion_7_days">Discussion
(7+ days)</h3>
<div class="gmail-level3">
<p>
Start Time: TBD<br>
End Time: TBD
</p>
</div>
<div class="gmail-secedit editbutton_section editbutton_4">
<form class="gmail-button gmail-btn_secedit
gmail-form-inline" method="post"
action="/scwg/sc48-domain_name_and_ip_address_encoding"></form>
</div>
<h3 class="gmail-sectionedit5"
id="gmail-vote_for_approval_7_days">Vote for approval (7
days)</h3>
<div class="gmail-level3">
<p>
Start Time: TBD<br>
End Time: TBD
</p>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Validation mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Validation@cabforum.org">Validation@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/validation">https://lists.cabforum.org/mailman/listinfo/validation</a>
</pre>
</blockquote>
<br>
</body>
</html>