<div dir="ltr">On Mon, Mar 19, 2018 at 6:25 PM, Peter Bowen <span dir="ltr"><<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.com</a>></span> wrote:<div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><span><br><blockquote type="cite"><div>On Mar 19, 2018, at 4:44 PM, Wayne Thayer <<a href="mailto:wthayer@mozilla.com" target="_blank">wthayer@mozilla.com</a>> wrote:</div><br class="m_3737474324090156508m_8596286445322625916m_3954154283655036396Apple-interchange-newline"><div><div dir="ltr">On Mon, Mar 19, 2018 at 9:16 AM, Peter Bowen via Validation <span dir="ltr"><<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><span><div><blockquote type="cite"><div>On Mar 17, 2018, at 7:43 AM, Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>> wrote:</div><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div class="m_3737474324090156508m_8596286445322625916m_3954154283655036396m_-1725030558274275201h5"><div><br></div></div></div></div></blockquote><div><span style="font-variant-ligatures:normal;font-variant-caps:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:inline">Consider the use of .7, in which we already permit (by virtue of CNAME) an expression of delegation to a separate entity via DNS.</span></div></div></div></div></div></blockquote></div></span></div></blockquote><div>From my understanding of the problem, this may be a solution that works for everyone. Is it correct that under the existing .7, a CA could instruct their customer to create a DNS CNAME in the '<a href="http://example.com/" target="_blank">example.com</a>' zone for '_www' that points to a DNS record controlled by the CA (e.g. '<a href="http://account1234.validation.megaca.com/" target="_blank">account1234.validation.megaca<wbr>.com</a>'), then perform .7 domain validation in perpetuity for '<a href="http://www.example.com/" target="_blank">www.example.com</a>' without any interaction from the DN Registrant?<br></div></div></div></div></div></blockquote><div><br></div></span><div>I think that would be allowed, but haven’t thought through all the implications of it being the CA itself.  I’ve only seen it used with CDNs and other delegation.</div><span><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><span><div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><span style="font-variant-ligatures:normal;font-variant-caps:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:inline">If the entire concern is that the respondant in WHOIS is not the PKI approver (preventing .2 and .3), and that the domain operator "for reasons" cannot configure one of the mailboxes (.4), would the expression of a domain record that allowed for a designated approver suffice? This could be established for all new/additional domains, can be verified technically, can be checked, and is "no worse" than setting a mailbox under .2/.4 or a CNAME under .7 to delegate to a PKI approver. Does this meet the needs? </span><br></div><div><span style="font-variant-ligatures:normal;font-variant-caps:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:inline"><br></span></div></div></div></div></div></blockquote></div></span></div></blockquote><div>My example above doesn't work for the Base Domain, so this makes sense. What would this special domain record contain?<br></div></div></div></div></div></blockquote><div><br></div></span><div>Your example above does work for a registered domain.  For example, given two records:</div><div><br></div><div>_<a href="http://pki-validation.example.com" target="_blank">pki-validation.example.com</a>. IN CNAME <a href="http://a852f14a-1bb5-4ab4-9050-7929605844ee.domainvalidation.acmecorpcdn.com" target="_blank">a852f14a-1bb5-4ab4-90<wbr>50-7929605844ee.domainvalidati<wbr>on.acmecorpcdn.com</a>.</div><div><br></div><div><a href="http://a852f14a-1bb5-4ab4-9050-7929605844ee.domainvalidation.acmecorpcdn.com" target="_blank">a852f14a-1bb5-4ab4-9050-792960<wbr>5844ee.domainvalidation.acmeco<wbr>rpcdn.com</a>. IN TXT 9b3d28ae4a6a4410bab518acc6<wbr>cbbe21</div><div><br></div><div>That could be used to validate the whole <a href="http://example.com" target="_blank">example.com</a> namespace.  The characters between “_” and “.” can be any valid DNS label and do not matter.</div><span><br></span></div></div></blockquote><div>Ah, yes. I missed that an **entire label** beginning with underscore could prefix the Authorization Domain Name. So now I really wonder if CAs could use this today to replace method #1?<br></div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><span><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span><div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><span style="font-variant-ligatures:normal;font-variant-caps:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:inline"></span></div><div><span style="font-variant-ligatures:normal;font-variant-caps:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:inline">Or consider d</span>uring the F2F, there was a discussion of expanding .12 in a way that the DNS Owner could put in a "challenge token" (of sorts) into WHOIS, which allowed them to uniquely and unambiguously link back to the notion of a CA account. Would such a link - in which the CA validated the existence (under the proposed ".13" rules, to be fleshed out) of this random token - suitably replace the need to do an organization-identity link? I think so.</div><div><br></div><div>However, if the proposal of the .1 supporters is that they should not have to consult DNS to verify an explicit authorization to delegate - such as a DNS record or (additional) WHOIS configuration - and instead rely on the mere existence of information that ICANN requires of domain holders - then that will remain unacceptable, as it's a fundamentally weak proposition.</div></div></div></div></div></blockquote></div></span></div></blockquote><div>I agree that an explicit authorization (similar to the approach proposed to "fix" .9 and .10) is much better, and I also question how useful an implicit but unambiguous WHOIS record match is outside of specific ccTLDs like the .no example we keep tossing around.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><span></span><div>These are both things worth introducing to the BRs and seeing if they meet needs.  </div><div><br></div></div></blockquote><div>If my understanding of the proposal above is in the ballpark, then the combination of these two with the new .12 seem to cover most of what was lost with #1. What do CAs who've been using .1 think?<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div></div><div>We should be biased towards including more validation methods in the BRs if they meet the bar for security, rather than trying to limit the number of options.  The BRs are very different from IETF RFCs as they are mandatory and validation methods are a closed set, so we cannot reasonably say “at least two independent interoperable implementations” as we likely won’t even have the first implementation of a method until well after a method is approved.</div><div><br></div><div>I put text forward for the .13 method in another email.  I hope that we can get it to a ballot soon so we can start to try it i the real world.  I also think DNS discovery of delegation of approval that you propose seems like a good path; it has the potential to allow delegation via multiple protocols via URI, which could offer a number of opportunities to improve the system.</div><div><br></div><div>Thanks,</div><div>Peter</div></div><br></blockquote></div></div></div>
</div></blockquote></span></div><br></div></blockquote></div><br></div></div></div>