[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 01:48:38 UTC 2018
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20180109/71429266/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list