<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 2, 2021 at 3:41 PM Tim Hollebeek via Validation <<a href="mailto:validation@cabforum.org">validation@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 lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-7284850198941946693WordSection1"><p class="MsoNormal">As discussed on the November 18th validation subcommittee call, <u></u><u></u></p><p class="MsoNormal">I offered to write some text that would clarify the importance <u></u><u></u></p><p class="MsoNormal">of binding the request to the customer when doing method 7, <u></u><u></u></p><p class="MsoNormal">for CAs that allow DNS delegation to a domain they control.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">For the purposes of starting the discussion, what about adding<u></u><u></u></p><p class="MsoNormal">the following text to the end of Method 7 (3.2.2.4.7), before<u></u><u></u></p><p class="MsoNormal">the ubiquitous Note:<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">---<u></u><u></u></p><p class="MsoNormal">CAs MAY operate domains for the purpose of assisting customers<u></u><u></u></p><p class="MsoNormal">with this validation, and MAY instruct customers to add a CNAME<u></u><u></u></p><p class="MsoNormal">redirect from an Authorization Domain Name to such a domain.<u></u><u></u></p><p class="MsoNormal">If the CA does so, the CA SHALL ensure that each domain name is<u></u><u></u></p><p class="MsoNormal">used for a unique Applicant, and not shared across multiple<u></u><u></u></p><p class="MsoNormal">Applicants.<u></u><u></u></p><p class="MsoNormal">---<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">This at least fixes the urgent problem, which is that some CAs<u></u><u></u></p><p class="MsoNormal">might currently be doing this in insecure ways.</p></div></div></blockquote><div><br></div><div>Just catching up on this post-break: I thought it was understood that CAs weren't allowed to do what's described above, as it stands in the current BRs.</div><div><br></div><div>The reason being that 3.2.2.4.7 requires the CA confirms the <i>Applicant's</i> control (the entity that operates the device, per 1.6.1), and the CA doing so would not be a demonstration of the Applicant's control.</div><div><br></div><div>Is this controversial / not well understood? Would people feel equally comfortable if a customer PBX system simply re-routed an extension back to a CA? Or, similarly, put the CA as the contact in 3.2.2.4.14?</div><div><br></div><div>The issue here is the entity performing the demonstration of control is also the entity that is "promoted" to the Subscriber upon issuance. A model where the CA demonstrated control would be the same as the CA becoming the Subscriber, right?</div><div><br></div><div>Is the argument that the CA is being designated an Applicant Representative? Doesn't that require explicitly natural (not legal) persons, and thus similarly limit such automation?</div><div><br></div><div>Maybe it'd be easier to help me understand how it's authorized if someone works from an assumption that "This is forbidden", and then works through the clauses that make it permissible.</div></div></div>