<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 8, 2018 at 6:05 AM, Dimitris Zacharopoulos <span dir="ltr"><<a href="mailto:jimmy@it.auth.gr" target="_blank">jimmy@it.auth.gr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><div><div class="gmail-h5">
<div class="gmail-m_8453899634594075284moz-cite-prefix">On 8/1/2018 11:24 πμ, Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Jan 8, 2018 at 4:11 AM,
Dimitris Zacharopoulos <span dir="ltr"><<a href="mailto:jimmy@it.auth.gr" target="_blank">jimmy@it.auth.gr</a>></span>
wrote:
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><span class="gmail-m_8453899634594075284gmail-">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>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?</div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</div>
</blockquote>
<br>
</span> 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. </div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">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. <br>
</div>
</blockquote>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>That seems like it would resolve the issues, right?</div>
</div>
</div>
</div>
</blockquote>
<br></div></div>
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.<br>
<br>
We already have a definition for Domain Name Registrar which covers
the ccTLD cases. <br>
<br>
"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)".<br>
<br>
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.<br>
<br>
How about using simpler language?<br>
<br>
"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."</div></blockquote><div><br></div><div>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). </div><div><br></div><div>A slight fix to your reword, to ensure it's clear as to what's being provided by the Registrar:</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div></div><br></div></div>