[gnso-rds-pdp-wg] Domain Name Certification was Re: Proposed Agenda for RDS PDP WG Meeting - 9 January at 17.00 UTC
Greg Shatan
gregshatanipc at gmail.com
Tue Jan 9 16:45:14 UTC 2018
Benny,
If you sincerely thought that’s what I was suggesting, you are mistaken.
If we are going to design new Certification protocols or procedures, we
should by all means learn from others. But that’s not within our remit —
not by a long shot. The question is whether Whois/RDS information is
necessary in any Certification process — and the answer to that is yes.
Whether there might be an alternative in the event of a Whois/RDS failure
is not the test we should be applying. If you lose your legs, there are
alternatives (wheelchairs, prosthetics). I don’t see anyone arguing that
legs are not necessary, much less breaking or sawing off their own legs or
those of others. (The movies “Misery” and “Boxing Helena” don’t count;
they are fiction, just like the alternatives that to Whois/RDS use that
don’t currently exist.)
If you are just “smarming” the list, I’ll refer you to John Bambanek’s
response.
Greg
On Tue, Jan 9, 2018 at 6:53 AM benny at nordreg.se <benny at nordreg.se> wrote:
> Sure lets not learn from others… That could be endanger the gTLD world.
> --
> 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 07:04, Greg Shatan <gregshatanipc at gmail.com> wrote:
> >
> > My understanding is that we are supposed to be looking at what is done,
> not what might be done in some future or alternate universe. The fact that
> some ccTLDs approach this another way has no bearing on how this is dealt
> with in the gTLDs.
> >
> > On Mon, Jan 8, 2018 at 10:50 PM benny at nordreg.se <benny at nordreg.se>
> wrote:
> > 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-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
> > >
> > > 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20180109/bd4bafeb/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list