<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I agree with Ryan's interpretation, and I'm against trying to
re-fashion the BRs or EV Guidelines along the lines of Kirk's
interpretation. As a practical matter I think it's impossible, and
as a matter of policy I think CAs and trust store operators would be
over-stepping to try to tell Example, Inc. what they can do with or
who they can authorize to operate on a sub-domain of their domain.<br>
<br>
As I see it CAs have two jobs when verifying a certificate, and
those jobs are certainly related but nevertheless separate:<br>
<br>
Job 1) Verify that the owner of the domain has authorized the
request (domain verification)<br>
This can take several forms, and as Ryan has pointed out, is
somewhat transitive, as by authorizing third parties to undertake
certain services, the domain owner by default authorizes them to
carry out certain functionality which has the practical result of
giving over domain control to those third parties. Those third
parties are therefore, by definition, authorized by the domain owner
to obtain certificates for the domain. The only way to change this
is to further change/restrict the methods of domain control
verification.<br>
<br>
In the case of a DV certificate, Job 1 is the only job (leaving
aside high-risk checks, etc) of the CA, and in this case the
Applicant is whoever submitted the request and, most likely,
controls the private key, though that's not necessarily the case.<br>
<br>
Job 2) In the case of OV/IV/EV the CA has the additional job to
verify the identity of the Organization or Individual to be named in
the Subject portion of the certificate, and confirm that the
Organization or Individual is aware of and authorizes the use of
their information in the certificate. Notice that I did not say,
"The organization or individual to whom the certificate is to be
issued." With OV/IV/EV things get switched around a bit, possibly,
and the organization or individual verified in this step IS the
Applicant by our definition, and by agreeing to be named in the
certificate, they are taking on the role of the responsible party
regardless of whether or not they 'own' the domain verified in #1,
and in fact, whether or not they control the private key or ever
even lay hands on the actual certificate. <br>
<br>
My personal view is this is as it should be, but even if you
disagree and think it should be otherwise, as a practical matter it
is simply not possible. Even if you restrict #1 to ONLY direct
contact with the domain registrant, because of private whois (you
have no clue who 'owns' example.com), OR in most cases, the ease of
changing WHOIS information you still couldn't restrict this. If a
CA tried to restrict Kirk Enterprises, LLC from obtaining a
certificate for kirk.example.com, but Example, Inc. wanted them to
have it, how hard is it for Example, Inc. to simply change the WHOIS
registrant information for a day? It's trivial, and it's therefore
a useless hoop which would be set up for no other reason than to
make it more difficult to obtain a certificate, or to make it more
difficult for the legitimate domain owner to do as they please with
their domain.<br>
<br>
Regards,<br>
Rich Smith<br>
<br>
<div class="moz-cite-prefix">On 11/20/2015 8:47 PM, Ryan Sleevi
wrote:<br>
</div>
<blockquote
cite="mid:CACvaWvbTUffjSLyf5uh0iW5-i-E_mQzEXBn0MOYHLv4SezyWBQ@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Nov 20, 2015 at 6:04 PM, <a
moz-do-not-send="true"
href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>
<span dir="ltr"><<a moz-do-not-send="true"
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 link="blue" vlink="purple" lang="EN-US">
<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 moz-do-not-send="true"
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 link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Having
said that, the
<u><a moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://example.com" target="_blank">example.com</a></u>
should be authenticated, and so the O field for <a
moz-do-not-send="true"
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
moz-do-not-send="true" 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 link="blue" vlink="purple" lang="EN-US">
<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 moz-do-not-send="true"
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
moz-do-not-send="true" 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 link="blue" vlink="purple" lang="EN-US">
<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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</body>
</html>