[gnso-rds-pdp-wg] Domain Name Certification was Re: Proposed Agenda for RDS PDP WG Meeting - 9 January at 17.00 UTC

Paul Keating Paul at law.es
Tue Jan 9 15:52:52 UTC 2018 

Chuck,

The point of my prior email is that your statement is true only based upon
the current RA and RAA.

From:  gnso-rds-pdp-wg <gnso-rds-pdp-wg-bounces at icann.org> on behalf of
Chuck <consult at cgomes.com>
Date:  Tuesday, January 9, 2018 at 3:38 PM
To:  'Greg Shatan' <gregshatanipc at gmail.com>, 'John Horton'
<john.horton at legitscript.com>
Cc:  <gnso-rds-pdp-wg at icann.org>
Subject:  Re: [gnso-rds-pdp-wg] Domain Name Certification was Re: Proposed
Agenda for RDS PDP WG Meeting - 9 January at 17.00 UTC

> For our purposes in our WG at this point in time, whether or not Whois is a
> necessary element in Certification is only essential for us to decide if it
> has an impact on the proposed WG agreement: ³Domain Name Certification is NOT
> a legitimate purpose for requiring collection of registration data, but may be
> a legitimate purpose for using some data collected for other purposes. (Access
> requirements to be deliberated at a later stage.)²
> 
>  
> 
> Chuck
> 
>  
> From: gnso-rds-pdp-wg [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of
> Greg Shatan
> Sent: Monday, January 8, 2018 7:38 PM
> To: John Horton <john.horton at legitscript.com>
> Cc: gnso-rds-pdp-wg at icann.org
> Subject: Re: [gnso-rds-pdp-wg] Domain Name Certification was Re: Proposed
> Agenda for RDS PDP WG Meeting - 9 January at 17.00 UTC
>  
> 
> Based on the responses from Greg A. And John, it seems that the statement that
> WHOIS is not a necessary element in Certification is factually incorrect. I'm
> not sure that we anywhere near agreement to the contrary. I would be quite
> uncomfortable with the idea that we are agreeing on something counter factual
> and that reality is being relegated to a dissent.  I'm also not sure that the
> nose-counting or voting or (preferably) consensus-building is done to the
> point where one point of view can be characterized as "the dissent."
> 
>  
> 
> Greg
>  
> 
> On Mon, Jan 8, 2018 at 8:49 PM John Horton via gnso-rds-pdp-wg
> <gnso-rds-pdp-wg at icann.org> wrote:
>> 
>> I recognize that the term Certification can have multiple meanings and apply
>> in different contexts (e.g., the CAB Forum guidelines for issuing certs
>> involve a very different type of circumstance than my company¹s,
>> LegitScript¹s, certification), but just a note that there are various
>> accreditation and certification authorities out there, including LegitScript,
>> that also verify that the Whois is a) not privacy protected, b) accurate and
>> c) has a logical nexus to the business in question, and d) extensively use
>> reverse Whois to assess the applicant¹s other business activities, as part of
>> a certification process that includes anti-AML protection. Valid, accurate
>> Whois is actually one of our eleven standards for certification, and if we
>> weren¹t able to 1) access the Whois and 2) conduct a full reverse Whois query
>> of those details, the accuracy of certification would suffer. Conversely, in
>> our world, we¹ve seen entities certified by other (less rigorous) companies
>> where the underlying brick-and-mortar pharmacy was valid, but the applicant
>> piggybacked onto the relationship to launder money for nefarious purposes,
>> and a simple Whois check revealed the illicit relationships. So: for
>> certification, which includes anti-money laundering protections, we certainly
>> need Whois as well as a rigorous reverse Whois function.
>> 
>>  
>> 
>> JCH
>> 
>>  
>> 
>> On Mon, Jan 8, 2018 at 5:31 PM Greg Aaron <gca at icginc.com> wrote:
>>> 
>>> In the CAB Forum guidelines for issuing certs, use of WHOIS records is
>>> important.  WHOIS records may not be the only way to obtain a cert, but in
>>> practice they are a main way to do so because WHOIS is an official and
>>> referenceable record.  David says that ³CAs are required to validate using
>>> information sources outside the RDS² but that does not mean that data in the
>>> RDS isn¹t used or needed.
>>>  
>>> From 
>>> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.1-redlined.p
>>> df 
>>>  
>>> 3.2.2.4.5 Domain Authorization Document
>>> Confirming the Applicant's control over the requested FQDN by relying upon
>>> the attestation to the authority of the Applicant to request a Certificate
>>> contained in a Domain Authorization Document. The Domain  Authorization
>>> Document MUST substantiate that the communication came from the Domain
>>> Contact. The CA MUST verify that the Domain Authorization Document was
>>> either (i) dated on or after the date of the domain validation request or
>>> (ii) that the WHOIS data has not materially changed since a previously
>>> provided Domain  Authorization Document for the Domain Name Space.
>>>  
>>> From the definitions section:
>>> * Domain Authorization Document:  Documentation provided by, or a CA¹s
>>> documentation of a communication with, a Domain Name Registrar, the Domain
>>> Name Registrant, or the person or entity listed in  WHOIS as the Domain Name
>>> Registrant (including any private, anonymous, or proxy registration service)
>>> attesting to the authority of an Applicant to request a Certificate for a
>>> specific Domain Namespace.
>>> * 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.
>>> * Domain Name Registrant:  Sometimes referred to as the ³owner² of a Domain
>>> Name, but more properly the  person(s) or entity(ies) registered with a
>>> Domain Name Registrar as having the right to control how a  Domain Name is
>>> used, such as the natural person or Legal Entity that is listed  as the
>>> ³Registrant² by WHOIS  or the Domain Name Registrar.
>>>  
>>> [emphases mine]
>>>  
>>> If contact data is not available in RDS, that will certainly place
>>> additional work on registrars, who will need to verify or vouch for their
>>> registrants to the CAs.
>>>  
>>>  
>>> 
>>> **********************************
>>> Greg Aaron
>>> Vice-President, Product Management
>>> iThreat Cyber Group / Cybertoolbelt.com
>>> mobile: +1.215.858.2257
>>> **********************************
>>> The information contained in this message is privileged and confidential and
>>> protected from disclosure. If the reader of this message is not the intended
>>> recipient, or an employee or agent responsible for delivering this message
>>> to the intended recipient, you are hereby notified that any dissemination,
>>> distribution or copying of this communication is strictly prohibited. If you
>>> have received this communication in error, please notify us immediately by
>>> replying to the message and deleting it from your computer.
>>>  
>>> 
>>> From: gnso-rds-pdp-wg [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf
>>> Of David Cake
>>> Sent: Monday, January 8, 2018 1:09 PM
>>> To: Lisa Phifer <lisa at corecom.com>
>>> Cc: gnso-rds-pdp-wg at icann.org
>>> Subject: [gnso-rds-pdp-wg] Domain Name Certification was Re: Proposed Agenda
>>> for RDS PDP WG Meeting - 9 January at 17.00 UTC
>>> 
>>>  
>>>  
>>> 
>>>                 As we hopefully prepare to finalise agreement on the whether
>>> or not domain name agreement on whether or not Domain Name Certification is
>>> a legitimate purpose for requiring collection of registrant data, I note
>>> that we had some dissenting points of view on the previous poll. I want to
>>> address those arguments, so it is clear that they were not ignored.
>>> 
>>>  
>>> 
>>>                 John Bambenek stated that ³the entire underpinning of TLS
>>> encryption requires validation of requesters and domain name owners.² -
>>> while there are some arguments about the detail of that statement (regarding
>>> the validation of domain based certificates, which require only validation
>>> of domain name control), its roughly correct - but the real issue here is
>>> that John¹s commennt does not address the primary argument, which is that
>>> (according to CAB Forum rules) CAs are required to validate using
>>> information sources outside the RDS, and as such, removing information which
>>> would be of only advisory value to the validation process of organisation
>>> and Extended Validation certificates should have no significant effect on
>>> the validation of the certificates that underpin TLS. See section 11.2.2 *
>>> 
>>>                 Where John¹s argument may be interpreted as an argument
>>> against the use of domain validation certificates, which do not attempt to
>>> validate based on identity of owners or ownership, but only on de facto
>>> control, the argument is outside the scope of the charter of this working
>>> group. 
>>> 
>>>  
>>> 
>>>                 Similarly, the comments from Tim O¹Brien that Œfor
>>> Organisational and Extended Validation to work, this information needs to be
>>> collected¹, seem to directly contradict the CAB Forum rules that directly
>>> state that for Organisational and Extended Validation, the CA must not rely
>>> on information from the RDS.
>>> 
>>>                
>>> 
>>>                 The comments from Rob Golding that  '³entity that controls
>>> the domain name² does not imply domain name registrant, and so conflates two
>>> different entities unnecessarily¹ is not I think correct, I think rather the
>>> opposite - Extended Validation certificates specifically do not attempt to
>>> guarantee that the certificate applicant IS the domain name registrant, but
>>> rather that they have a right to control it (note primary purpose of EV Cert
>>> 2.1.1 (1), and Warranties 7.1.C, and explicit wording Œowned or controlled
>>> by¹ in 9.2.2). So there is no conflation, rather a precise distinguishing
>>> between the purpose of RDS data (which relates to registrant), and the
>>> purpose of EV etc Certificates. Domain certificates are a different case, in
>>> that they are generally validated by the de facto demonstration of domain
>>> name control only - which again, is not guaranteed to be the registrant.
>>> 
>>>  
>>> 
>>>                 Two people suggested modifications to the text.
>>> 
>>>                 Rod Rasmussen suggests that Domain Name Certification may be
>>> a legitimate purpose for optional collection of registration data at the
>>> request of the registrant. While it is hard to argue unambiguously against
>>> such a limited statement, I am not sure that even in such a form it is true.
>>> It is hard to see how even a very optional form of data could be
>>> legitimately used by a CA for validation, given the explicit rules against
>>> doing so. Rod, if you have a specific example in mind I¹d be interested -
>>> otherwise it would seem to be somewhat speculative.
>>> 
>>>                
>>> 
>>>                 Maxim Alzoba suggests that the ambiguity between use and
>>> collection could create a problem (specifically with the GDPR), and suggests
>>> we reword to avoid this issue. While I disagree with the argument, more
>>> importantly I think we should revisit this when we address access issues,
>>> rather than confuse the issue of our discussion of collection.
>>> 
>>>  
>>> 
>>> *             [all references to rules here from CA/B Forum Guidelines For
>>> The Issuance And Management Of Extended Validation Certificates, version
>>> 1.6.5]
>>> 
>>>  
>>> 
>>>                 Regards
>>> 
>>>  
>>> 
>>>                                 David
>>> 
>>>  
>>>> 
>>>> On 9 Jan 2018, at 1:06 am, Lisa Phifer <lisa at corecom.com> wrote:
>>>>  
>>>> 
>>>> Dear all,
>>>> 
>>>>  
>>>> 
>>>> The next GNSO Next-Gen RDS PDP Working Group meeting will take place on
>>>> Tuesday 9 January 2018 at 17:00 UTC.
>>>> 
>>>>  
>>>> 
>>>> The proposed agenda (below) and meeting materials (attached) are also
>>>> posted on the meeting page: https://community.icann.org/x/QgByB
>>>> <https://community.icann.org/x/QgByB>
>>>> 
>>>>  
>>>> 
>>>> Regards,
>>>> 
>>>> Lisa
>>>> 
>>>>  
>>>> PROPOSED AGENDA ­ RDS PDP WG Call on Tuesday 9 January 2018 at 17:00 UTC
>>>> 
>>>>  
>>>> 
>>>> 1. Roll Call/SOI Updates
>>>> 
>>>> 2. Complete deliberation on data required for Domain Name Management
>>>> 
>>>>    a. Review poll results from 20 December call Question 2
>>>> 
>>>>    b. Finalize agreement on data required for Domain Name Management
>>>> 
>>>> 3. Complete deliberation on Domain Name Certification
>>>> 
>>>>    a. Review poll results from 20 December call Question 3
>>>> 
>>>>    b. Finalize agreement on Domain Name Certification as a legitimate
>>>> purpose 
>>>> 
>>>> 4. Start deliberation on ³Criminal Activity/ DNS Abuse ­ Investigation²
>>>> 
>>>> 5. Confirm action items and proposed decision points
>>>> 
>>>> 6. Confirm next WG meeting: Tuesday, 16 January at 17:00 UTC
>>>> 
>>>>  
>>>> 
>>>> Meeting Materials: https://community.icann.org/x/QgByB
>>>> <https://community.icann.org/x/QgByB>
>>>> 
>>>> Note: Attached call handout includes poll results and the definitions
>>>> produced by DT7
>>>> 
>>>>  
>>>> 
>>>>  
>>>> <Handout-9January-RDSWGCall-v3.pdf>________________________________________
>>>> _______
>>>> gnso-rds-pdp-wg mailing list
>>>> gnso-rds-pdp-wg at icann.org <mailto:gnso-rds-pdp-wg at icann.org>
>>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>>> <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
>>>  
>>> _______________________________________________
>>> gnso-rds-pdp-wg mailing list
>>> gnso-rds-pdp-wg at icann.org
>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>> _______________________________________________
>> gnso-rds-pdp-wg mailing list
>> gnso-rds-pdp-wg at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
> _______________________________________________ gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20180109/3d3dddb1/attachment-0001.html>

More information about the gnso-rds-pdp-wg mailing list