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