<div dir="ltr">We'll put this into ballot format then and introduce it.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 8, 2021 at 3:00 PM Ben Wilson via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org">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">Here is a link to the current redline. <a href="https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation" target="_blank">https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation</a> <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 8, 2021 at 2:05 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">It has been proposed that we add the following language to the end of the third paragraph of BR section 4.2.1:  "Effective 2021-10-01, the CA SHALL verify Domain Names and IP Addresses no more than 398 days prior to Certificate issuance." Is this language clear enough?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 25, 2021 at 11:55 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"><div>Hi Bruce,</div><div><br></div><div>See my responses inline below. <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 22, 2021 at 2:17 PM Bruce Morton <<a href="mailto:Bruce.Morton@entrust.com" target="_blank">Bruce.Morton@entrust.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 lang="EN-US">
<div>
<p class="MsoNormal">Hi Ben,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">A couple of comments. <u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The ballot does not address the “cliff” that CAs have stated will occur. </p></div></div></blockquote><div><br></div><div>I do not see a "cliff" - it is more like a small hump. <br></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 lang="EN-US"><div><p class="MsoNormal">The thinking is that currently CAs are verifying domains, which can be reused for 825-days (~27 months). </p></div></div></blockquote><div><br></div><div>Agreed - currently CAs can reuse domain verification for 
825-days (~27 months). However, they should not be reusing FQDN and IP address verification for such a long period, especially for one-year certificates. There should only be a very small number of domains that are difficult to verify, and if they've verified once before, then customers and CAs should have procedures in place that can be re-performed.<br></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 lang="EN-US"><div><p class="MsoNormal">The new requirement implies that the domain verification can
 only be reused for 398-days (~13 months). </p></div></div></blockquote><div><br></div><div>The new requirement would apply to certificates issued on or after July 1, 2021.  This proposal does not require all certificate validations to be redone, and the most recent verifications are more likely to still be accurate. <br></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 lang="EN-US"><div><p class="MsoNormal">This means that for CAs which reuse domain validation, there will be 14 months of validation which will expire on the effective date of the ballot. </p></div></div></blockquote><div><br></div><div>Correct, but the 14 months of validation would be for those old validations that were performed nearly 3 years ago -- from approximately October 5, 2018 through December 6, 2109.<br></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 lang="EN-US"><div><p class="MsoNormal">In many cases this may create a lot of work on the Subscriber and
 the CA to revalidate these domains. </p></div></div></blockquote><div><br></div><div>I disagree.  As stated above, there should be fewer reuse of validations performed. I don't know of any statistics supporting the amount of work that would need to be performed.  Shouldn't these processes be automated?  Do you have data for the type of validations that were originally performed between October 5, 2018 and December 6, 2109, to indicate how many of those will be problematic?  Also, 
the July 1, 2021, date has been circulated by Mozilla for quite some time, and CAs should have been preparing for it.<br></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 lang="EN-US"><div><p class="MsoNormal">Is it possible to have the ballot only address domains which are validated after the effective date? The domains which are currently validated can be reused per their current schedule.</p></div></div></blockquote><div><br></div><div>We can discuss this more, but your request is just that new domains and IP addresses be validated - which would already be required with or without an amendment to policy.  I think the currently proposed amendment is the best approach. <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 lang="EN-US"><div><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Would it also be possible to push out the effective date by a quarter, so October 1, 2021? </p></div></div></blockquote><div><br></div><div>That might be a possibility, but doesn't that just move your "cliff".  As I say above, CAs and customers should 
already 

be moving toward more frequent FQDN and IP Address verification.<br></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 lang="EN-US"><div><p class="MsoNormal">This will give the CAs more time to implement the change and to advise Subscribers of the impact. It will also give the Subscribers some time to
 address the volume of domains which will have to be re-validated.</p></div></div></blockquote><div><br></div><div>What is the volume of domains that will need to be revalidated?  Two-year certificates were eliminated last year, but how many 2-year certificates would be coming up for renewal, and of those, how many had problematic domain validation procedures that would need to be re-performed or replaced with the currently allowed methods?<br></div><div> </div><div>Respectfully,</div><div><br></div><div>Ben</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 lang="EN-US"><div><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks, Bruce.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><b>From:</b> Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org" target="_blank">servercert-wg-bounces@cabforum.org</a>>
<b>On Behalf Of </b>Ben Wilson via Servercert-wg<br>
<b>Sent:</b> Friday, February 19, 2021 2:14 PM<br>
<b>To:</b> CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>><br>
<b>Subject:</b> [EXTERNAL] Re: [Servercert-wg] Reducing Domain/IP Address Validation Reuse to 398 Days<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">WARNING: This email originated outside of Entrust.<br>
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.<u></u><u></u></p>
<div class="MsoNormal" style="text-align:center" align="center">
<hr width="100%" size="2" align="center">
</div>
<div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<div>
<p>Name of Ballot:  398-Day Reuse<u></u><u></u></p>
<p>Purpose of Ballot: <u></u><u></u></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. <u></u><u></u></p>
<p>Specifically: <u></u><u></u></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.
<u></u><u></u></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.
<u></u><u></u></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.
<u></u><u></u></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.
<u></u><u></u></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.”
<u></u><u></u></p>
<p>* It replaces eight instances of “thirteen months/thirteen-month” in EVG 11.14.3 with 398 days.
<u></u><u></u></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.
<u></u><u></u></p>
<p>– MOTION BEGINS – <u></u><u></u></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:
<u></u><u></u></p>
<p>MODIFY the Baseline Requirements as defined in the following redline: <a href="https://urldefense.com/v3/__https:/github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation__;!!FJ-Y8qCqXTj2!Pw5FPlsjcApvD6B-RB2ue9k4OrfoZk-pK2UyHBEE5gpaRDKbgxwu90dLVaBfS1OrxQc$" title="https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation" 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) 
<u></u><u></u></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:
<u></u><u></u></p>
<p>MODIFY the EV Guidelines as defined in the following redline: <a href="https://urldefense.com/v3/__https:/github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation__;!!FJ-Y8qCqXTj2!Pw5FPlsjcApvD6B-RB2ue9k4OrfoZk-pK2UyHBEE5gpaRDKbgxwu90dLVaBfS1OrxQc$" title="https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation" 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)
<u></u><u></u></p>
<p>– MOTION ENDS – <u></u><u></u></p>
<p>This ballot proposes two Final Maintenance Guidelines. <u></u><u></u></p>
<p>The procedure for approval of this ballot is as follows: <u></u><u></u></p>
<p>Discussion (7+ days) <u></u><u></u></p>
<p>Start Time: TBD<u></u><u></u></p>
<p>End Time: TBD <u></u><u></u></p>
<p>Vote for approval (7 days) <u></u><u></u></p>
<p>Start Time: TBD <u></u><u></u></p>
<p>End Time: TBD <u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">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:<u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">See <a href="https://urldefense.com/v3/__https:/github.com/BenWilson-Mozilla/servercert/commit/26bd5a9f9f8bd2a251153a4cceb6226b859a3464__;!!FJ-Y8qCqXTj2!Pw5FPlsjcApvD6B-RB2ue9k4OrfoZk-pK2UyHBEE5gpaRDKbgxwu90dLVaBfndkviR8$" target="_blank">
https://github.com/BenWilson-Mozilla/servercert/commit/26bd5a9f9f8bd2a251153a4cceb6226b859a3464</a><u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Mon, Feb 15, 2021 at 11:44 AM Ben Wilson <<a href="mailto:bwilson@mozilla.com" target="_blank">bwilson@mozilla.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">I have created a GitHub branch to make changes in for this ballot.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><a href="https://urldefense.com/v3/__https:/github.com/BenWilson-Mozilla/servercert/tree/398-day-FQDN-validation/docs__;!!FJ-Y8qCqXTj2!Pw5FPlsjcApvD6B-RB2ue9k4OrfoZk-pK2UyHBEE5gpaRDKbgxwu90dLVaBfI2S_Sds$" target="_blank">https://github.com/BenWilson-Mozilla/servercert/tree/398-day-FQDN-validation/docs</a>
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I intend to replace "thirteen months" in section 11.14.3 of the EV Guidelines with "398 days".
<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">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:<u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">All,<u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Arial",sans-serif">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, "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><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">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.
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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 ...."  <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Ben<u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="https://urldefense.com/v3/__https:/lists.cabforum.org/mailman/listinfo/servercert-wg__;!!FJ-Y8qCqXTj2!Pw5FPlsjcApvD6B-RB2ue9k4OrfoZk-pK2UyHBEE5gpaRDKbgxwu90dLVaBfywc1So8$" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><u></u><u></u></p>
</blockquote>
</div>
</blockquote>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="https://urldefense.com/v3/__https:/lists.cabforum.org/mailman/listinfo/servercert-wg__;!!FJ-Y8qCqXTj2!Pw5FPlsjcApvD6B-RB2ue9k4OrfoZk-pK2UyHBEE5gpaRDKbgxwu90dLVaBfywc1So8$" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</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>
_______________________________________________<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>
_______________________________________________<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>