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

Dimitris Zacharopoulos jimmy at it.auth.gr
Mon Jan 8 09:59:22 MST 2018



On 8/1/2018 6:29 μμ, Tim Hollebeek wrote:
>
>  
>
> I think you and Ryan are on the right track.
>
>  
>
> I’ve expressed before an interest in explicitly allowing RDAP in
> addition to WHOIS (I don’t support the idea of making the requirement
> more generic because security analysis is much more difficult for
> generic requirements).
>
>  
>
> It wouldn’t be a bad thing if at the same time we added explicit
> requirements around the acceptable ways to directly contact a domain
> registrar.  Like Rich, I want to see the details so I can determine
> whether the requirements make sense.
>

I can describe the case of Registrars in Greece (under the gr ccTLD).
They usually provide a signed letter that includes domain name and
Registrant information (administrative contact, technical contact,
organization name, telephone numbers and e-mail addresses) which is
usually enough information for a CA to use and validate Domain ownership
via 3.2.2.4.2 or 3.2.2.4.3.

Registrars have official telephone numbers and e-mail addresses to be
contacted and this information is publicly provided by the National
registry. It doesn't have to be just WHOIS or RDAP.

For the case where the CA is also a Registrar, the "signed letter" part
can be skipped, since, as a Registrar, the Domain Contact information is
already known. In fact, it is even better because if a Domain has
expired and the CA/Registrar gets a  Certificate Request for that
Domain, it will not issue because they know it is expired and will (most
likely) not rely on previous information, as non-Registrar CAs would
normally do.

I could provide more details if necessary.


Dimitris.

>  
>
> I was asked on Thursday to split 218 into two ballots, since it seems
> #1 will take a little more work than #5.  #5 seems uncontroversial,
> but I keep getting requests for a longer timeline (possibly phased,
> with strong requirements to eliminate the egregious problems early)
> for #1.
>
>  
>
> Should we have two ballots so we can eliminate #5 early, while making
> reasonable improvements to #1?
>
>  
>
> BTW, for those who have asked, the ballot 217 “you have the time you
> need” discussion requirements was the reason I wasn’t overly concerned
> about when I posted the ballot.
>
>  
>
> -Tim
>
>  
>
> 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?
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20180108/9997c69d/attachment.html>


More information about the Public mailing list