<div dir="ltr"><div>Hi Ben,</div><div><br></div><div>Do you need help preparing this for GitHub? Happy to help, but since I noticed it's the second proposal from you, I wasn't sure if it was intentional, but happy to start something so that we can collaboratively edit and discuss in context.</div><div><br></div><div>Further responses inline, below.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 8, 2021 at 3:03 PM Ben Wilson <<a href="mailto:bwilson@mozilla.com">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><span style="font-family:arial,sans-serif"><font size="4">Here are my initial thoughts:</font></span></div><div><span style="font-family:arial,sans-serif"><font size="4"><br></font></span></div><div><span style="font-family:arial,sans-serif"><font size="4">In BR Section 4.2.1, add a sentence - 









<u><span style="line-height:107%">This
does not apply to the validation of domain authorization or control performed
under Section 3.2.2.4 or the authentication of an IP address performed under Section
3.2.2.5.</span></u></font></span></div></div></blockquote><div><br></div><div>So, if you want to go this route, 4.2.1 will need other updates, because this section also has this phrase "Applicant information MUST include, but not be limited to, at least one Fully-Qualified Domain Name or IP Address to be included in the Certificate's subjectAltName extension".</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%">In BR Section 3.2.2.4 add, </span><span style="line-height:107%">"<span style="line-height:107%"><u>For
Certificates issued on or after July 1, 2021, the CA SHALL verify that each FQDN
is current and correct at intervals of 398 days or less</u>."</span></span></font></span></div><div><span style="font-family:arial,sans-serif"><font size="4"><u><span style="line-height:107%"><u><span style="line-height:107%"><br></span></u></span></u></font></span></div><div><span style="font-family:arial,sans-serif"><font size="4"><span style="line-height:107%"><span style="line-height:107%">In BR Section 3.2.2.5 add, <span></span>









"<u><span style="line-height:107%">For
Certificates issued on or after July 1, 2021, the CA SHALL verify that each IP address
is current and correct at intervals of 398 days or less.</span></u></span></span></font></span></div></div></blockquote><div><br></div><div>What is "current and correct"? This seems subject to significant issues in interpretation, and I could easily drive a truck through possible loopholes. So I'm probably missing something at the core: What was the thinking that led to tackling it this way, versus other past efforts? Was it simply to try and explicitly carve out the data with respect to 3.2.2.4 and 3.2.2.5? Or were their other considerations?</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>



</span></span></font></span></div><div><span style="font-family:arial,sans-serif"><font size="4"><span style="line-height:107%"><span style="line-height:107%"><br></span></span></font></span></div><div><span style="font-family:arial,sans-serif"><font size="4"><span style="line-height:107%"><span style="line-height:107%">Replace in both sections, "</span></span><span style="line-height:107%"><span style="line-height:107%"><span style="line-height:107%">In
all cases, the validation must have been initiated within the time period
specified in the relevant requirement (such as Section 4.2.1 of this document)
prior to Certificate issuance."  with "<span style="line-height:107%"><u>In
all cases, the validation must have been completed within the 398 days preceding certificate issuance.</u>"</span></span></span></span></font></span></div><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%"><br></span></span></span></span></font></span></div><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.4.6 to remove any exception that would still allow CA to "continue to re-use information and validations for domains validated under this method per the applicable certificate data reuse periods."  (The Method 6 was deprecated June 3, 2020.)</span></span></span></span></font></span></div></div></blockquote><div><br></div><div>If you're touching this (and I agree, it's reasonable to touch), then I think we should also be touching the other places, like 3.2.2.4.3 (May 31, 2019)</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><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"><br></font></span></div><div><span style="font-family:arial,sans-serif"><font size="4">Tie up any other loose ends.  For instance, do we leave the EV guidelines alone at thirteen months for Domain Names? See EVG section 11.14.3(1)(F).</font></span></div></div></blockquote><div><br></div><div>Yes, I was going to say that anytime we've touched this, we've had to touch both documents.</div><div><br></div></div></div>