[cabfpub] FW: New subject -- Applicant/Subscriber versus domain Registrant

[Rich Smith]

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.

As I see it CAs have two jobs when verifying a certificate, and those 
jobs are certainly related but nevertheless separate:

Job 1) Verify that the owner of the domain has authorized the request 
(domain verification)
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.

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.

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.

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.

Regards,
Rich Smith

On 11/20/2015 8:47 PM, Ryan Sleevi wrote:
>
>
> On Fri, Nov 20, 2015 at 6:04 PM, kirk_hall at trendmicro.com 
> <mailto:kirk_hall at trendmicro.com> <kirk_hall at trendmicro.com 
> <mailto:kirk_hall at trendmicro.com>> wrote:
>
>
>     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.
>
>
> 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.
>
> 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.
>
> Consider the practical implications of this - who has the obligation 
> to protect the private key? The logical operator of kirk.example.com 
> <http://kirk.example.com> - Kirk Hall - may never be in possession of 
> the private key.
>
>     Having said that, the _kirk.example.com <http://kirk.example.com>_
>     example below does raise some tough questions.  I would start by
>     saying that only the domain _example.com <http://example.com>_
>     should be authenticated, and so the O field for kirk.example.com
>     <http://kirk.example.com> should say O= Example Corp. only.
>
>
> I disagree, the majority of CAs in practice disagree, and the BRs do 
> as well, but at least it helps understand your view :)
>
> There is no obligation to authenticate the 'example.com 
> <http://example.com>' part - you can authenticate at the FQDN level. 
> Indeed, it is extremely common AND desirable to do this.
>
> 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.
>
>      However if there is a desire or commercial need for certs for
>     _kirk.example.com <http://kirk.example.com>_ 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 example.com <http://example.com> 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.
>
>
> 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.
>
> 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.
>
>     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 _different_ 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").
>
>
> 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"
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151123/4071eef9/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4035 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151123/4071eef9/attachment-0001.p7s>