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

[Tim Hollebeek]

I’m not sure there are other valid cases (in fact I suspect there are not), but Wayne mentioned on the validation WG call that he’s concerned that this change could be very disruptive if not handled carefully, and I’m sympathetic to that concern.  Especially since on the same call he also pointed out the same flaw that Dimitris did …

 

I’m certainly not going to rule out the idea that there might be reasonable improvements to the ballot that other people will think of that we had not!  After all, we already have an existence proof …

 

-Tim

 

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Monday, January 8, 2018 9:34 AM
To: Tim Hollebeek <tim.hollebeek at digicert.com>
Cc: Dimitris Zacharopoulos <jimmy at it.auth.gr>; CA/Browser Forum Public Discussion List <public at cabforum.org>; Rich Smith <richard.smith at comodo.com>
Subject: Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

 

I'm not sure that's a good approach - namely, "making reasonable improvements to #1" is, I think, a question of whether there are _other_ cases beyond the one identified (in which WHOIS is not available).

 

Thus, I think framing it as 'reasonable improvements' may be implying there are other valid cases for #1, which I don't think has been provided. If we framed it as "If we remove #1, are there any other valid cases beyond the no-WHOIS TLDs that may be impacted"?

 

For concrete examples, I don't think the .no case is a good one :)

 

On Mon, Jan 8, 2018 at 11:29 AM, Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > 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 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://lists.cabforum.org/pipermail/public/attachments/20180108/fa88873a/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180108/fa88873a/attachment-0003.p7s>