[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
Wed Jan 10 13:40:05 UTC 2018
As I have noted in prior emails, the issue can be easily solved if ICANN
was to require the collection and certification in its contracts with
Registries and obligate the Registries to impose it with Registrars, etc
and down the line to registrants.
On 1/10/18, 7:26 AM, "gnso-rds-pdp-wg on behalf of benny at nordreg.se"
<gnso-rds-pdp-wg-bounces at icann.org on behalf of benny at nordreg.se> wrote:
>Right but that might be legitimate purpose for viewing the data for
>systems / persons who need to view the data. But it does not equal
>purpose to collect the data.
>
>There are a huge difference in what we need to collect and what we would
>like to collect for all involved with working with these data.
>Purpose for collection must match the actual use for registrering a
>domain to be compliant with contractual agreements. The purpose are not
>to collect data for an external system using these data upon request.
>Nowhere in the registrar agreement or the registry agreement with ICANN
>is it stated that the data collected have to satisfy external systems use
>of data or that it shall be collected for such use.
>
>
>--
>Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
>
>Benny Samuelsen
>Registry Manager - Domainexpert
>
>Nordreg AB - ICANN accredited registrar
>IANA-ID: 638
>Phone: +46.42197000
>Direct: +47.32260201
>Mobile: +47.40410200
>
>> On 9 Jan 2018, at 14:51, Greg Aaron <gca at icginc.com> wrote:
>>
>> The question is not "Do we need to collect data to satisfy others
>>systems beyond the domain registration?" The question is": "Who owns
>>(who is the registrant of) a domain name? Who is responsible for it,
>>who controls it?"
>>
>> All kinds of parties need to know the answer. Referring to the
>>official record is the way to provide the answer. The official record
>>is the registration data, provided by an RDS.
>>
>>
>> **********************************
>> 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.
>>
>> -----Original Message-----
>> From: gnso-rds-pdp-wg [mailto:gnso-rds-pdp-wg-bounces at icann.org] On
>>Behalf Of benny at nordreg.se
>> Sent: Monday, January 8, 2018 10:50 PM
>> To: Greg Shatan <gregshatanipc at gmail.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
>>
>> I might be mistaken but my understanding on the question are as follows:
>>
>> Do we need to collect data to satisfy others systems beyond the domain
>>registration? My take on this is no, if we look isolated on the
>>registration.
>> Data used by others based on historical (present) publication should
>>not be a reason for collecting data in the future just based on the fact
>>that it is how we do it today.
>>
>> The DV certificates are working fine on ccTLD¹s without whois data
>>today with other methods for approval.
>>
>>
>> --
>> Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
>>
>> Benny Samuelsen
>> Registry Manager - Domainexpert
>>
>> Nordreg AB - ICANN accredited registrar
>> IANA-ID: 638
>> Phone: +46.42197000
>> Direct: +47.32260201
>> Mobile: +47.40410200
>>
>>> On 9 Jan 2018, at 04:38, Greg Shatan <gregshatanipc at gmail.com> wrote:
>>>
>>> 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-redlin
>>>ed.pdf
>>>
>>>
>>>
>>> 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
>>>
>>>
>>>
>>> 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
>>>
>>> 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
>>> 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
>>
>> _______________________________________________
>> 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
More information about the gnso-rds-pdp-wg
mailing list