<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Kirk,</div><div class=""><br class=""></div><div class="">I think there might be some misunderstanding about how the validation methods covered in Ballot 169 work. Each method, with one exception, already includes either Base Domain Name, Authorization Domain Name, or Domain Namespace. This was extremely intentional when the Validation Working Group was drafting the methods. The only place where there is any possible confusion is whether a confirming response received within 30 days of creation of a Random Value can be used after 30 days. As a member of the WG, I am confident that the intent was the answer is yes; the 30 day clock stops once the response is received and that received response (including the timestamp when it was received) can be used for the 4.2.1 duration.</div><div class=""><br class=""></div><div class="">Below are all methods and where Base Domain Name, Authorization Domain Name, or Domain Namespace come into play (or don’t). In putting this together, one thing that stood out is the 3.2.2.4.5 has specific requirements for reuse that seem to conflict with the added “Note”, which seems to be a problem.</div><div class=""><br class=""></div><div class="">Hopefully this helps explain why the Validation WG didn’t include the type of “note” language in 169 that is proposed here.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Peter</div><div class=""><br class=""></div><div class="">3.2.2.4.1: Validating the Applicant as a Domain Contact</div><div class=""><br class=""></div><div class="">"validating the Applicant is the Domain Contact”: the definition of Domain Contact is "the Domain Name Registrant, technical contact, or administrative contract (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS SOA record.”</div><div class=""><br class=""></div><div class="">This clearly calls out Base Domain Name. If the CA has previously obtained documents and data that shows that the Applicant is the Domain Contact, then they can reuse these to confirm the new request, as long as the documents and data were obtained within the period specified in 4.2.1. For example, an applicant requests <a href="http://www.example.com" class="">www.example.com</a>, the CA confirms the application is a domain contact for <a href="http://example.com" class="">example.com</a>. Later the same application applies for <a href="http://shop.example.com" class="">shop.example.com</a>, and the CA uses the documents and data from the first verification to again verify the applicate is a domain contact for <a href="http://example.com" class="">example.com</a>.</div><div class=""><br class=""></div><div class="">3.2.2.4.2: Email, Fax, SMS, or Postal Mail to Domain Contact</div><div class=""><br class=""></div><div class="">“MUST be sent to an email address, fax/SMS number, or postal mail address identified as a Domain Contact.”</div><div class=""><br class=""></div><div class="">Again, uses Domain Contact which explicitly invokes Base Domain Name. In this case the CA would likely use record of a timely confirming response as documents and data to reuse. This is one where the working group may want to consider making it clear that the 30 days is only when the response must have been received, not when it was used to complete the verification.</div><div class=""><br class=""></div><div class="">3.2.2.4.3: Phone Contact with Domain Contact</div><div class=""><br class=""></div><div class="">"MUST place the call to a phone number identified by the Domain Name Registrar as the Domain Contact”</div><div class=""><br class=""></div><div class="">Again, uses Domain Contact which explicitly invokes Base Domain Name. As before, the CA would likely use record of a timely confirming response as documents and data to reuse.</div><div class=""><br class=""></div><div class="">3.2.2.4.4: Constructed Email to Domain Contact</div><div class=""><br class=""></div><div class="">"sending an email to one or more addresses created by [...] at-sign ("@") followed by an Authorization Domain Name”</div><div class=""><br class=""></div><div class="">This explicitly calls out Authorization Domain Name. As with 3.2.2.4.2, the CA would likely use record of a timely confirming response as documents and data to reuse. This is another one where the working group may want to consider making it clear that the 30 days is only when the response must have been received, not when it was used to complete the verification.</div><div class=""><br class=""></div><div class="">3.2.2.4.5: Domain Authorization Document</div><div class=""><br class=""></div><div class="">"Documentation [...] attesting to the authority of an Applicant to request a Certificate for a specific Domain Namespace”</div><div class=""><br class=""></div><div class="">This explicitly uses Domain Namespace and has an explicit reuse provision "the WHOIS data has not materially changed since a previously provided Domain Authorization Document for the Domain Name Space” Unlike some of the other methods, the CA is explicitly required to recheck whois each time a certificate is issued.</div><div class=""><br class=""></div><div class="">3.2.2.4.6: Agreed-Upon Change to Website</div><div class=""><br class=""></div><div class="">"Authorization Domain Name” is directly called out in the validation method.</div><div class=""><br class=""></div><div class="">3.2.2.4.7: DNS Change</div><div class=""><br class=""></div><div class=""><div class="">"Authorization Domain Name” is directly called out in the validation method.</div></div><div class=""><br class=""></div><div class="">3.2.2.4.8: IP Address</div><div class=""><br class=""></div><div class="">Intentionally does not use Base Domain Name, Authorization Domain Name, or Domain Namespace</div><div class=""><br class=""></div><div class="">3.2.2.4.9: Test Certificate</div><div class=""><br class=""></div><div class=""><div class="">"Authorization Domain Name” is directly called out in the validation method.</div></div><div class=""><br class=""></div><div class="">3.2.2.4.10: TLS Using a Random Number</div><div class=""><br class=""></div><div class=""><div class="">"Authorization Domain Name” is directly called out in the validation method.</div></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 6, 2017, at 4:25 PM, Kirk Hall via Public <<a href="mailto:public@cabforum.org" class="">public@cabforum.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">We have had this same conversation several times now, and yet keep coming back to the same points.<br class=""><br class="">As I and others have said, including on today's call, without the Note there is uncertainty as to whether there is specific authorization for CAs who have validated a domain ("<a href="http://example.com" class="">example.com</a>") using Methods 1-7 and 9-10 to then issue certs to the same customer for domains that include additional nodes to the left (<a href="http://www.example.com" class="">www.example.com</a>, <a href="http://mail.example.com" class="">mail.example.com</a>) based on the prior validation of <a href="http://example.com" class="">example.com</a>. I think some have even questioned whether or not CAs can do this (a common practice today among CAs and their customers) in the various email strings we have had over the past few months. That's the only reason we have felt the need to add specific provisions like the Note to what was in Ballot 169 - these questions were raised, and the interpretations were offered on existing language.<br class=""><br class="">Some CAs in the past relied on Method 7 "any other method" as authority to issue for an FQDN that was a validated FQDN plus nodes to the left. The terms Authorization Domain Name and Base Domain may be a good way to go in the future, but they are only found in a few of the ten validation methods - maybe they should be added to the other methods by the Validation Working Group in the follow-up ballot to come, but we can't rely on those terms today. <br class=""><br class="">If you look at the discussion of the past two weeks alone, we have had multiple formulations of the best language to explicitly allow CAs to do this, and finally I picked the most recent one - Gerv's - because it seemed to be well stated and do what we all want to do.<br class=""><br class="">While you indicated on the call today that the Note at the end of each validation method could introduce uncertainty and also IP risk, you did not elaborate or provide details. I don't agree with you, but if you have additional details and examples to support your conclusions I'll be happy to review them. Even better, if you want to draft replacement language that accomplishes what we are trying to accomplish, please do and we can take a look.<br class=""><br class="">For all these reasons (as we have discussed before), we will keep the Note in the Ballot 190 as shown in v5, but if you want to draft an immediate follow-on ballot that addresses your concerns, we can take that up immediately after Ballot 190 passes. The most important thing now is to try to get this ballot enacted, get the new validation methods in the BRs, and eliminate "any other method" for user security.<br class=""><br class="">-----Original Message-----<br class="">From: Ryan Sleevi [<a href="mailto:sleevi@google.com" class="">mailto:sleevi@google.com</a>] <br class="">Sent: Thursday, July 6, 2017 12:29 PM<br class="">To: Kirk Hall <<a href="mailto:Kirk.Hall@entrustdatacard.com" class="">Kirk.Hall@entrustdatacard.com</a>>; CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" class="">public@cabforum.org</a>><br class="">Subject: [EXTERNAL]Re: [cabfpub] Updated Ballot 190 v5 dated July 6, 2017<br class=""><br class="">Kirk,<br class=""><br class="">Just because it's important to capture for those who were not on the call - since it's likely this ballot will proceed to voting before such minutes are available, a few thoughts from the call to be<br class="">captured:<br class=""><br class="">1) At least one member highlighted the concern that, by making modifications to this ballot, as proposed, this introduces additional IP risk that the Forum was specifically trying to address with Bylaws 1.6. The best path to address this risk is to remove the "Note"<br class=""><br class="">2) At least one member highlighted that the Validation WG, with the proposal of Ballot 169, spent considerable time trying to address the ambiguity problem that the "Note" is trying to address (but does so incompletely).<br class=""><br class="">3) At least one member highlighted that the "Note", by being non-normative, is neither urgent nor essential to resolve in this version. However, by introducing the currently proposed language, it creates potential issues that there is no guarantee will be able to be resolved easily or in a timely fashion. As the Forum already has methods to address ambiguity - both through the questions@ list and through subsequent ballots - it seems far more appropriate to remove the proposed text, thus aligning with Ballot 169, and thus resolving a significant objection towards forwards progress.<br class=""><br class="">I do not understand, nor agree with, the proposal to force a vote on this, when concerns have been repeatedly raised, and which are trivial to address in a way that allows us to make forward progress on the far more substantive aspect.<br class=""><br class="">Further, I have not seen any attempt to address and/or resolve the concerns highlighted in <a href="https://cabforum.org/pipermail/public/2017-July/011492.html" class="">https://cabforum.org/pipermail/public/2017-July/011492.html</a><br class=""><br class="">As the ballot proposer, can you please make an effort to address and/or respond to these concerns, which introduce substantially new risk and confusion? I have hopefully provided clear suggestions about ways to resolve, and it's unclear whether your lack of acknowledgement represents a need for additional time to review (in which case, we should stop the discussion period), a disagreement on principle (in which case, I hope you can clearly state so), or if my concerns are unclear (in which case, we should stop the discussion period, and I'm more than happy to work with you to explain them).<br class=""><br class="">I understand and appreciate your eagerness to see this through to conclusion, but believe it at least deserves some response and engagement on the substance of these real and pressing security concerns, rather than dismissing them as fixing them after. After all, it is worth noting that it has taken us nearly a year to get to this point in which we're somewhat close to a ballot, so you can understand why I am quite troubled by the suggestion that we can somehow quickly fix these real security issues after-the-fact.<br class=""><br class="">On Thu, Jul 6, 2017 at 2:39 PM, Kirk Hall via Public <<a href="mailto:public@cabforum.org" class="">public@cabforum.org</a>> wrote:<br class=""><blockquote type="cite" class="">Based on the CABF teleconference discussion today, it’s clear there is <br class="">still a difference of opinion on the best way to express the ability <br class="">of a CA to re-use the validation of an FQDN and issue certs for other <br class="">FQDNs that include additional nodes to the left (except for validation Method 8).<br class="">Jeremy and Ben are collecting all the suggestions for how to express <br class="">this, and once Ballot 190 is adopted will immediately consider appropriate edits.<br class="">But we need to get Ballot 190 done in order to end the “any other method”<br class="">authorization and meet Mozilla deadlines as well.<br class=""><br class=""><br class=""><br class="">For now, we have this formulation of the rule posted by Gerv last <br class="">Friday, which looks good to me:<br class=""><br class=""><br class=""><br class="">“Note: Once the FQDN has been validated using this method, the CA MAY <br class="">also issue Certificates for other FQDNs that end with all the labels <br class="">of the validated FQDN and have more labels than it.”<br class=""><br class=""><br class=""><br class="">I have dropped in that language in the attached Version 5 of Ballot <br class="">190 (and specified this is not true for Method 8). Otherwise, the <br class="">ballot is the same as v4 which was previously circulated.<br class=""><br class=""><br class=""><br class="">Ballot 190 v5 (6-30-2017) is now the official Ballot 190 under <br class="">consideration by the Forum. The discussion period ends on July 8 at <br class="">18:00 UTC, after which voting will start.<br class=""><br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">Public mailing list<br class=""><a href="mailto:Public@cabforum.org" class="">Public@cabforum.org</a><br class="">https://cabforum.org/mailman/listinfo/public<br class=""><br class=""></blockquote>_______________________________________________<br class="">Public mailing list<br class=""><a href="mailto:Public@cabforum.org" class="">Public@cabforum.org</a><br class="">https://cabforum.org/mailman/listinfo/public<br class=""></div></div></blockquote></div><br class=""></body></html>