Thanks for your interesting analysis. It reminds me of Rich’s point that if we allow method 1 submethod 3 (now method 12) to continue, maybe it requires more details.
I think my personal preference is that method 12 is fine as it is right now, though maybe it is something we should continue to look at, since several of the issues you raised at the end are not specific to method 12, but could result in improvements to the related methods (2 and 3) as well. So maybe we shouldn’t try to roll these concerns into Ballot 218. What do others think? -Tim From: Ryan Sleevi [mailto:[email protected]] Sent: Monday, January 15, 2018 1:38 PM To: Tim Hollebeek <[email protected]> Cc: CA/Browser Forum Public Discussion List <[email protected]>; Daymion T. Reynolds <[email protected]> Subject: Re: Applicant vs Applicant representative On Mon, Jan 15, 2018 at 3:00 PM, Tim Hollebeek <[email protected] <mailto:[email protected]> > 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 [email protected] <mailto:[email protected]> 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 [email protected] <mailto:[email protected]> 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 <http://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 <http://example.com> " configuration 2) Distinct sign-ins for Alice, Bob, and Carol, each marking them as authorized to manage any/all of "example.com <http://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 <http://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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
