<div dir="ltr"><div>Here is a preliminary, rough draft of Ballot SC42 for discussion and comment. Please let me know if you spot any deficiencies in required content or procedure.<br></div><div>In other words, this email is not intended to and does not begin the discussion period on this ballot. A separate, official email will be sent out next week for that purpose.<br></div><div>
<div>
<p>Name of Ballot: 398-Day Reuse<br>
</p><p>Purpose of Ballot:
</p>
<p>
This ballot changes validation reuse periods for FQDN and IP Address validation in the Baseline
Requirements and for all purposes in the EV Guidelines.
The ballot does not change the 825-day reuse period in section 4.2.1. of
the Baseline Requirements for Organizational Validation (OV)
information.
</p>
<p>
Specifically:
</p>
<p>
* It inserts in BR section 3.2.2.4 “For Certificates issued on or after
July 1, 2021, the CA SHALL verify that each FQDN is confirmed as
permitted by this section at intervals of 398 days or less.” It also
requires that the validation be completed within the 398 days preceding
certificate issuance and removes cross-references to BR section 4.2.1.
</p>
<p>
* It modifies BR sections 3.2.2.4.3 and 3.2.2.4.6 to eliminate reuse of
FQDN validation performed under those sunsetted provisions.
</p>
<p>
* It modifies BR section 3.2.2.4.7 to replace subsections i. and ii. with a 30-day limit on reuse of the Random Value.
</p>
<p>
* It inserts in BR section 3.2.2.5 “For Certificates issued on or after
July 1, 2021, the CA SHALL validate each IP address as permitted by this
section at intervals of 398 days or less.” It also requires that the
validation be completed within the 398 days preceding certificate
issuance and removes cross-references to BR section 4.2.1.
</p>
<p>
* It clarifies BR section 4.2.1 by stating, “This 825-day period does
not apply to the validation of domain authorization or control performed
under [Section
3.2.2.4](#3224-validation-of-domain-authorization-or-control) or the
authentication of an IP address performed under [Section
3.2.2.5](#3225-authentication-for-an-ip-address), which have a 398-day
reuse period.”
</p>
<p>
* It replaces eight instances of “thirteen months/thirteen-month” in EVG 11.14.3 with 398 days.
</p>
<p>
The following motion has been proposed by Ben Wilson of Mozilla and
endorsed by Dimitris Zacharopoulos of HARICA and Chema Lopez of
Firmaprofesional.
</p>
<p>
– MOTION BEGINS –
</p>
<p>
This ballot modifies the “Baseline Requirements for the Issuance and
Management of Publicly-Trusted Certificates” (“Baseline Requirements”),
based on Version 1.7.3:
</p>
<p>
MODIFY the Baseline Requirements as defined in the following redline: <a href="https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation" title="https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation" rel="nofollow" target="_blank">https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation</a> (GITHUB URL TO BE UPDATED)
</p>
<p>
This ballot modifies the “Guidelines for the Issuance and Management of
Extended Validation Certificates” (“EV Guidelines”) as follows, based on
Version 1.7.4:
</p>
<p>
MODIFY the EV Guidelines as defined in the following redline: <a href="https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation" title="https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation" rel="nofollow" target="_blank">https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation</a>
(GITHUB
URL TO BE UPDATED)
</p>
<p>
– MOTION ENDS –
</p>
<p>
This ballot proposes two Final Maintenance Guidelines.
</p>
<p>
The procedure for approval of this ballot is as follows:
</p>
<p>
Discussion (7+ days)
</p>
<p>
Start Time: TBD</p>
<p>
End Time: TBD
</p>
<p>
Vote for approval (7 days)
</p>
<p>
Start Time: TBD
</p>
<p>
End Time: TBD
</p>
</div>
</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 15, 2021 at 11:50 AM Ben Wilson via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</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">See <a href="https://github.com/BenWilson-Mozilla/servercert/commit/26bd5a9f9f8bd2a251153a4cceb6226b859a3464" target="_blank">https://github.com/BenWilson-Mozilla/servercert/commit/26bd5a9f9f8bd2a251153a4cceb6226b859a3464</a></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 15, 2021 at 11:44 AM Ben Wilson <<a href="mailto:bwilson@mozilla.com" target="_blank">bwilson@mozilla.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>I have created a GitHub branch to make changes in for this ballot.<br></div><div><a href="https://github.com/BenWilson-Mozilla/servercert/tree/398-day-FQDN-validation/docs" target="_blank">https://github.com/BenWilson-Mozilla/servercert/tree/398-day-FQDN-validation/docs</a> <br></div><div>I intend to replace "thirteen months" in section 11.14.3 of the EV Guidelines with "398 days". <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 9, 2021 at 5:03 PM Ben Wilson via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</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"></div>All,<br><div class="gmail_quote"><div dir="ltr"><div><span style="font-family:arial,sans-serif"><font size="4"><br><u><span style="line-height:107%"></span></u></font></span></div></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 class="gmail_quote"><div></div><div> </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><span style="font-family:arial,sans-serif"><font size="4"><span style="line-height:107%"><span style="line-height:107%"><span style="line-height:107%"><span style="line-height:107%">Amend BR section 3.2.2.5.1 and possibly make the Random Value valid for only 30 days or 60 days because what is meant by "if the Applicant submitted the certificate request"? Otherwise, just editing out some of the existing language it would read something like,</span></span></span></span><span style="line-height:107%"> "If a Random
Value is used, the CA SHALL provide a Random Value unique to the certificate
request and SHALL not use the Random Value after the longer of (i) 30 days or
(ii) if the Applicant submitted the certificate request, 398 days," but someone should explain how that makes any sense.</span></font></span></div></div></blockquote><div><br></div><div>I seem to recall that harmonizing the Random Value (which, I agree, is also a good change) touches a few other sections. In particular, we identified previously that the (ii) is an anti-pattern; that is, that the Random Value should be valid 30 days or less, and it's the cached validation that is reused after that, rather than the Random Value itself. We updated several of the places, but not all. That is, 3.2.2.4.7 also needs to be cleaned up</div><div> </div></div></div></blockquote><div>
Can someone propose alternative language that says what was intended (i.e. "cached validation" as indicated by Ryan)? Otherwise, in BR section 3.2.2.4.7 (DNS Change) and BR section 3.2.2.5.1 (Agreed Upon Change to Website), as part of this proposed ballot, I intend to limit use of the Random Value to 30 days and delete the phrase "ii. if the Applicant submitted the Certificate request, the timeframe permitted for reuse of validated information relevant to the Certificate (such as in Section 4.2.1 of these Guidelines or Section 11.14.3 of the EV Guidelines)" because it makes no sense as currently worded. In any event, even the structure is bad because it combines two unrelated conditions into one concept. In other words, it wouldn't make sense to say the longer of (i) 30 days or (ii) 398 days for cached validations. As proposed by the ballot, the 398-day limit will apply to all methods of validation. <br></div><div><br></div><div>I am still a little unclear on the intent of the language in (ii). Would the intent have been better served if that second part had been placed in a separate sentence? E.g., "The same Random Value may also be used for submitting subsequent certificate requests for the same domain for the timeframe permitted for reuse ...." </div><div><br></div><div>Thanks,</div><div><br></div><div>Ben<br></div></div></div>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote></div>
</blockquote></div></div>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote></div>