[cabfpub] Ballot 218: Remove validation methods #1 and #5

[Ryan Sleevi]

On Mon, Jan 8, 2018 at 6:05 AM, Dimitris Zacharopoulos <jimmy at it.auth.gr>
wrote:

> On 8/1/2018 11:24 πμ, Ryan Sleevi wrote:
>
>
>
> On Mon, Jan 8, 2018 at 4:11 AM, Dimitris Zacharopoulos <jimmy at it.auth.gr>
> wrote:
>>
>> An example of pre-existing TLD adhering to this is .gov (in the US) - and
>> I'm guessing you know of one or more ccTLDs that also fit into this
>> category?
>>
>> The advantage being is that this permits non-gTLDs (i.e. those within the
>> ICANN sphere of oversight) to use methods 'equivalent' to WHOIS. The
>> disadvantage is that, in the absence of the registry agreements, the level
>> of assurance or equivalence of those respective methods is at the
>> determination of the ccTLD/TLD operator and the CA, and not uniform in
>> assurance or reliability.
>>
>>
>> The level of assurance for Domain Contact phone numbers and e-mail
>> addresses is pretty much the same in most gTLD, ccTLD cases, that's why I
>> proposed that they are combined with methods 3.2.2.4.2 or 3.2.2.4.3.
>>
>
> I don't believe we can simply state this. That is, we can objectively
> evaluate, say, the ICANN Registry agreement, and the means in which the
> information is provided and maintained, and make a determination on that.
> Outside of those cases - legacy TLDs and ccTLDs - it's less clear that we
> can objectively reach the same conclusions.
>
>
>> I am hoping to have the WHOIS "equivalent" methods for all Domains. We
>> are talking about Domain Validation methods so I don't think we should use
>> "Organization Information" of WHOIS or Domain Registrar records to validate
>> Domain ownership.
>>
>
> I wonder, then, if it would resolve your concerns about the removal of
> 3.2.2.4.1 to update the Domain Contact method - the issues I highlighted on
> variability notwithstanding. That is, it sounds like we're in agreement
> that 3.2.2.4.1, as worded, is entirely ambiguous as to the level of
> assurance provided. The methods of contacting in 3.2.2.4.2/.3 are
> acceptable, the only question is how we determine the information. We allow
> WHOIS, for example, but as worded, it would preclude RDAP or other forms,
> and would preclude the cases (such as .gov) in which direct registry
> contact is required.
>
> Domain Contact: The Domain Name Registrant, technical contact, or
> administrative contract (or the equivalent under a ccTLD) as provided by
> the Domain Registrar or, for TLDs in which the Registry provides
> information, the Registry. Acceptable methods of determination include the
> WHOIS record of the Base Domain Name, within a DNS SOA record [Note: This
> includes the hierarchal tree walking, by virtue of 3.2.2.4's recursion], or
> through direct contact with the applicable Domain Name Registrar or Domain
> Name Registry.
>
> This can then be separately expanded to RDAP, or be moved more formally in
> to a section within 3.2 as to acceptable methods for the determination of
> the Domain Contact (e.g. moving the normative requirements for validation
> outside of the definition).
>
> That seems like it would resolve the issues, right?
>
>
> I am a bit confused about the agreements part between registries and
> registrars but I don't think it is a blocking factor for our discussion. At
> the end of the day, the Domain owner provides contact information to a
> Registrar and these records are kept by the Registrar. Registrars probably
> don't need to validate anything (e-mail addresses, phone numbers). Domain
> owners have the incentive to provide accurate information so that they can
> be contacted if something bad happens with their Domain. If this
> information is inaccurate, the CA will probably not be able to reach the
> Domain owner to validate. There have been cases of Domain hijacking but I
> don't think that the CA/Browser Forum should try to solve this problem.
>
> We already have a definition for Domain Name Registrar which covers the
> ccTLD cases.
>
> "Domain Name Registrar: A person or entity that registers Domain Names
> under the auspices of or by agreement with: (i) the Internet Corporation
> for Assigned Names and Numbers (ICANN), (ii) a national Domain Name
> authority/registry, or (iii) a Network Information Center (including their
> affiliates, contractors, delegates, successors, or assigns)".
>
> We don't currently define "Registry" but there are several places where we
> use "registry-controlled, or public-suffix". Perhaps we can leave it as is.
>
> How about using simpler language?
>
> "Domain Contact: The Domain Name Registrant, technical contact, or
> administrative contract (or the equivalent under a ccTLD) as listed in the
> WHOIS record of the Base Domain Name or in a DNS SOA record or through
> direct contact with the Domain Name Registrar."
>

The issue I was highlighting, which I think is not quite captured by the
simpler language, is situations where there is a registry without a
registrar. The separation of these two activities was a result of the ICANN
discussions, and some ccTLDs have a single organization perform what is
logically the "registrar" functions and the "registry" functions. I'm not
sure our current definition of Registrar fully encompasses that, but I'm
also willing to see a view that these single-organization functions are
within the auspices of (themselves) or agreement with (themselves).

A slight fix to your reword, to ensure it's clear as to what's being
provided by the Registrar:

Domain Contact: The Domain Name Registrant, technical contact, or
administrative contract (or the equivalent under a ccTLD) as listed in the
WHOIS record of the Base Domain Name or in a DNS SOA record, or as obtained
through direct contact with the Domain Name Registrar.

then I think we're in agreement that the 3.2.2.4.2/3.2.2.4.3 would be
sufficient for non-WHOIS providing ccTLDs, without requiring the ambiguity
of 3.2.2.4.1, and resolving the issue Jeremy highlighted about potential
misinterpretation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180108/3c5b43ad/attachment-0003.html>