[gnso-rds-pdp-wg] Domain Name Certification was Re: Proposed Agenda for RDS PDP WG Meeting - 9 January at 17.00 UTC

David Cake dave at davecake.net
Mon Jan 8 18:08:34 UTC 2018


	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 <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 <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 <mailto:gnso-rds-pdp-wg at icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <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/a84c3a9a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20180109/a84c3a9a/signature.asc>


More information about the gnso-rds-pdp-wg mailing list