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

[Ryan Sleevi]

On Fri, Nov 20, 2015 at 6:04 PM, kirk_hall at trendmicro.com <
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 - 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 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' 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 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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151120/77c5446c/attachment-0003.html>