[gnso-rds-pdp-wg] Domain Name Certification was Re: Proposed Agenda for RDS PDP WG Meeting - 9 January at 17.00 UTC
John Horton
john.horton at legitscript.com
Tue Jan 9 20:26:10 UTC 2018
Let me respond to Chuck's earlier email (and I'm sort of responding to
Benny and others here too) with one point that I hope is relevant to argue
why we *shouldn't have consensus* around the statement in question. Just to
frame the context, Chuck had noted:
"...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.)'"*
In other words, I think the point Chuck was making here (correct me if I'm
wrong) is that we're looking at possible consensus around that statement,
and specifically whether domain name certification is a legitimate purpose
for requiring collection of registration data.
I'd argue against consensus (indeed, I'd argue in favor of consensus as to
the opposite statement) for the following reasons. Simply put, there are
some registrars or registries (particularly but not only in the health
space) where certification is in fact required for use of some domain
names, and to do that, you have collect the registration data so that the
certifier has the data to review. :) Sure, the "certification" is broader
than merely certifying the accuracy and relevance of the Whois record, but
that's a key part of what we're certifying. To make it absolutely clear,
the registrant can't use the domain name for some purposes until
certification has been completed. So, unless this group wants to tell those
registries and registrars that they can't do that any longer (and I believe
that some of the specialty gTLDs actually referenced those processes in
their ICANN applications), it seems pretty fact-based to me that domain
name certification IS, in fact, a legitimate purpose for requiring
collection of registration data. I mean, it's currently happening in some
cases -- how can this group possibly reach consensus that it's not a
legitimate purpose when it's already happening?
Which (sort of?) leads me to respond to to Benny's point (and Benny, I'm
not trying to misrepresent your email, so apologies if I'm getting it
wrong!), I guess the point I'd make is -- well, I guess it depends on what
type of internet we want to have, right? I mean, we can absolutely say that
certification isn't a legitimate purpose, but really -- is that truly the
kind of internet we want, where anti-abuse and certification activity is so
curtailed? Isn't that a little bit of an overly activist approach for this
group? That simply makes no sense to me. There are in fact high-risk areas,
and there are some instances in which certifying the registrant, including
their registration details, is part of a trust and safety policy.
John Horton
President and CEO, LegitScript
*Follow LegitScript*: LinkedIn
<http://www.linkedin.com/company/legitscript-com> | Facebook
<https://www.facebook.com/LegitScript> | Twitter
<https://twitter.com/legitscript> | *Blog <http://blog.legitscript.com/>*
| Newsletter <http://go.legitscript.com/Subscription-Management.html>
On Tue, Jan 9, 2018 at 12:09 PM, Greg Aaron <gca at icginc.com> wrote:
> But just because there are multiple methods does not mean that using
> registration data to vet certificates is an illegitimate usage.
>
>
>
> If one wants to know who is responsible for a domain name, one can write
> to the registrar, or one can use the RDS.
>
> To find a book, I can use the physical library card catalog, or I can use
> the online catalog.
>
> To get to work, I can ride a horse, or I can use a wheeled vehicle.
>
> Online catalogs and wheeled vehicles are not required. But they are
> legitimate solutions to a problem, and are more suited than the
> alternatives.
>
>
>
>
>
>
>
> *From:* David Cake [mailto:dave at davecake.net]
> *Sent:* Tuesday, January 9, 2018 12:56 PM
> *To:* Greg Aaron <gca at icginc.com>
> *Cc:* Lisa Phifer <lisa at corecom.com>; 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
>
>
>
> That is one of multiple methods possible for Validation of Domain
> Authorisation or Control. As it is one of multiple methods, it is not
> required.
>
>
>
> David
>
>
>
>
>
> On 9 Jan 2018, at 9:30 am, 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.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 <http://cybertoolbelt.com/>
>
> mobile: +1.215.858.2257 <(215)%20858-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
> <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20180109/5a9c59de/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list