<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 20, 2015 at 6:04 PM, <a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a> <span dir="ltr"><<a href="mailto:kirk_hall@trendmicro.com" target="_blank">kirk_hall@trendmicro.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><br></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I think our current BR language, including the definition of Applicant and Applicant Representative, encompasses this situation (agents acting on behalf of the website owner)
 pretty well now, so I don’t see a problem or a need for change for that situation.</span></p></div></div></blockquote><div><br></div><div>Unfortunately, while I can understand the appeal of your analysis, I think I'd have to disagree, which is why Peter's changes are worthwhile.</div><div><br></div><div>Further, consider the situation about possession of private key - one of the obligations of Subscriber Agreements. In these cases, it may be any number of parties who has the private key - and indeed, you'll recall that Gerv brought this up as an example of further muddying the waters.</div><div><br></div><div>Consider the practical implications of this - who has the obligation to protect the private key? The logical operator of <a href="http://kirk.example.com">kirk.example.com</a> - Kirk Hall - may never be in possession of the private key.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Having said that, the
<u><a href="http://kirk.example.com" target="_blank">kirk.example.com</a></u> example below does raise some tough questions.  I would start by saying that only the domain
<u><a href="http://example.com" target="_blank">example.com</a></u> should be authenticated, and so the O field for <a href="http://kirk.example.com" target="_blank">kirk.example.com</a> should say O= Example Corp. only. </span></p></div></div></blockquote><div><br></div><div>I disagree, the majority of CAs in practice disagree, and the BRs do as well, but at least it helps understand your view :)</div><div><br></div><div>There is no obligation to authenticate the '<a href="http://example.com">example.com</a>' part - you can authenticate at the FQDN level. Indeed, it is extremely common AND desirable to do this.</div><div><br></div><div>It's OK that we disagree, in as much as we recognize it's a point of disagreement (like I mentioned and gave the past examples). The question is whether or not we can recognize that disagreement, ensure that the proposed language from the VWG doesn't try to (rather through accident or intent) subtlely restrict/resolve that disagreement, and then work as a separate effort to find a common interpretation and agreement. That was, respectively, the path i), ii), and iii) I had suggested - agree that we disagree, agree that we're not trying to solve that right now, and agree to continue the common, widely practiced solution - until iv), where we can look to change things or provide greater clarity, as appropriate.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">  However if there is a desire or commercial need for certs for
<u><a href="http://kirk.example.com" target="_blank">kirk.example.com</a></u> where the Applicant wants O=Kirk Enterprises LLC, then we can probably accommodate that by creating some new, more restrictive vetting rules in the BRs for authenticating at third level domains or higher (where the customer does not
 want the O field information to represent the owner of the SLDN).  And if there is a problem with our rules today on this point (for example, if the wrong party is listed in the O field for <a href="http://example.com" target="_blank">example.com</a> because of use of a practical demonstration method), let’s
 work on that.  It may not be misrepresentation by the Applicant or a bad certificate if the SLDN owner has authorized it.</span></p></div></div></blockquote><div><br></div><div>I think it's rather the inverse, and that was more my point. This ship has sailed - the industry practice and the interpretation of the BRs as applied by member CAs and Root Stores do not, in practice, observe your interpretation.</div><div><br></div><div>As such, I'm more inclined to have the language reflect the reality and the interpretation, than attempt to (and this is admittedly, subjective) needlessly restrict it through unrelated efforts.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">However, some responsibility or blame should extend to the owner of an SLDN if the owner allows a web hoster or other third party improperly to confirm ownership of the SLDN
 to a <u>different</u> party by using an email method or practical demonstration to misrepresent the owner to the issuing CA – the owner of the SLDN should lock down what the web hoster can do with the domain…  If the actual owner of the SLDN clicks a link
 or cooperates to show some other party as owner of the SLDN in a FQDN during domain authentication (or the web hoster does that), that’s potantially a misrepresentation to the CA that could lead to revocation of the cert if the CA finds out and does not receive
 a satisfactory explanation (such as “we have licensed the use of the domain to that other party, so it’s ok”).</span></p></div></div></blockquote><div><br></div><div>I must apologize, I've read this several times and am unclear the point you were trying to make with obligations, and certainly not sure how you imagine this working at a technical level; the examples I gave show the improbability-to-impossibility of the "owner of an SLDN [being able to] lock down what the web hoster can do with the domain"</div></div></div></div>