[cabfpub] Applicant vs Applicant representative

[Ryan Sleevi]

On Mon, Jan 15, 2018 at 3:00 PM, Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> Forking off to a new thread because it doesn't really need to block Ballot
> 218, and as Ryan noted, the issue might exist elsewhere.
>

> I don't think 12 and 3 are completely parallel cases.
>
> In 3, you are calling the Domain Contact on the phone.  This is fine
> because they are the Domain Contact.  That person may be neither the
> Applicant nor the Applicant representative, but they are presumably
> authoritative about issues of domain control, by virtue of being a Domain
> Contact.  I think this is your point.
>

Yup.


> In 12, you're trying to verify that the Applicant is the Domain Contact.
> This makes sense in cases where the Applicant is the Domain Name
> Registrant.


One down :)


> I'm struggling to understand what it means to compare the Applicant to the
> "technical contact" or "administrative contact" listed in WHOIS.


What about a technical contact that itself establishes a legal entity
separate from the Domain Name Registrant? For example, a technical contact
of MarkMonitor?


> Who do I compare the fictional entity dns-admin at google.com with Google?
> Do we really mean "Applicant is the Domain Name Registrant", since unless
> you're a person, your administrative contact and technical contact will not
> be the Applicant?


> But I think we intended to allow the technical contact and administrative
> contact to be authoritative.  So maybe "Applicant is the Domain Name
> Registrant or the Applicant Representative is the technical contact or
> administrative contact, as listed in WHOIS" ?
>

I don't think that would meet the goal, since that would mean you've simply
shifted the burden from assuming dns-admin at google.com is a Legal Entity to
assuming it is a natural person, and in both cases, you're assuming. Using
the MarkMonitor example, why should we prevent legal entities from serving
as the technical or administrative contacts?

(Incidentally, it's worth noting here we have a typo of "administrative
contract" in Domain Contact, rather than "administrative contact")


> Maybe there's no problem here, but there do seem to be cases where #12 is
> attempting to compare apples and oranges.
>

I suppose it's worth making this concrete:

Imagine you are a "CA Foo" who also has an Affiliate/Subsidiary "Registrar
Bar"

"Registrar Bar" has a relationship with "Example, Inc", the operators of
example.com
Alice, Bob, and Carol are all employees of "Example, Inc" and authorized to
make changes to DNS and to approve certificates
Bob is listed as the Technical Contact
Carol is listed as the Administrative Contact

You can imagine a system at "Registrar Bar" several ways that manages this.
1) A single, shared log-in account that Alice, Bob, and Carol (the natural
persons) all use to manage the "example.com" configuration
2) Distinct sign-ins for Alice, Bob, and Carol, each marking them as
authorized to manage any/all of "example.com"

Questions emerge from both cases:
A) For #1, how do you determine that the Applicant (which might
specifically be Alice, Bob, or Carol on behalf of "Example, Inc", or may be
abstractly *anyone* from "Example, Inc") is the Domain Name Registrant?
B) For #1, how do you determine that the account being used is by the
natural person "Bob" or by the natural person "Carol", rather than Alice?
C) For #2, what authority, if any, does Alice have, as an Applicant
Representative (presumably) who is not the technical or administrative
contact, and not specifically the abstract-Applicant (merely acting on
behalf of/as an agent of)
D) For either case, under your proposed language, what happens if it is for
a TLD not under WHOIS? (For example, a CA that is also a/is an affiliate of
a ccTLD NIC, as some members are)

I would pose that, regardless of #1 or #2, we want to ensure that Alice,
Bob, and Carol are all authorized to request certificates - and conversely,
to reject certificates. This is derived from Section 4.1.2 of the BRs,
which allows the Applicant Representative to make requests on behalf of the
Applicant.

I think this naturally leads to a conclusion that, regardless of
implementation #1 or implementation #2, Alice, Bob, and Carol, as Applicant
Representatives, all serve logically as the Applicant, and their accounts
logically serve to confirm that the Applicant is the Domain Contact
(whether the singular account used to manage "Example, Inc's" example.com
domains or the multiple accounts used to do so)

So that leaves just one last part of your question - what about when Bob is
the Technical Contact / Carol is the administrative contact? In those
cases, the CA must take extra steps (if they don't apriori know that Bob or
Carol are Applicant Representatives), and that's by using 3.2.2.4.2 or
3.2.2.4.3, with "CA Foo" directly contacting "Registrar Bar" (aka
themselves/their affiliate) to determine that the contact information for
Bob/Carol, and then contacting them as appropriate. This would address the
Issue D I raised - by saying it's not handled by 3.2.2.4.1 at all.

I'm sure this is 'as clear as Mississippi mud' - so the summary version is:
- if the CA is the Registrar/an affiliate, than any account that can modify
that domain logically constitutes the Applicant Representative acting on
behalf of the Applicant, and that the Applicant is the Domain Name
Registrant, ergo satisfies being the Domain Name Contact, and 3.2.2.4.12
applies
- If the CA is the registrar/an affiliate, and wants to reach out to the
Administrative or Technical contact (which are *not* published via WHOIS),
they can use the 'direct contact' method to talk to themselves, determine
who the Administrative or Technical contacts are, and then validate the
request under 3.2.2.4.2 or 3.2.2.4.3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180115/e33755e7/attachment-0003.html>