- Gnso-rds-pdp-3 - lists.icann.org

Draft answers
by David Cake March 13, 2018

March 13, 2018

The new work is now overdue, as we should already have distributed it to the rest of the working group in order that people may read it for the meeting. So I am going to prepare and submit a draft agreement, if you believe that my summary does not represent drafting team consensus, please let me know ASAP. I think this is pretty straightforward and uncontroversial. I basically took what we had already agreed, noted references to CA/Browser Forum documents where applicable, and expanded the detail of the methods in three methods in 3.2.2.4 in detail. I left in some discussion of Extended Validation, but made clear it is only to demonstrate the general inapplicability of additional EV requirements for discussion. As timing is very late, I will send this through to the Working Group directly in a minute or two, but there is still time to amend this before (or when( it is presented to the group. David ————— Drafting Team 3 Domain Name Certification 1. Who associated with the domain name registration needs to be identified and/or contacted for the purpose of Domain Name Certification? A person who is able to demonstrate ownership or control over the domain name. 2. What is the objective achieved by identifying and/or contacting each of those entities? By ensuring the certificate is granted only to an entity that is able to demonstrate ownership or control over the domain name, the trustworthiness of the certificate system is increased, in order to better achieve the primary goal, which is to enable efficient and secure electronic communication. Reference: CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates version 1.5.6, (henceforth the CA/B Baseline Requirements) section 1.4.1 Appropriate Certificate Uses 3. What might be expected of that entity with regard to the domain name? An applicant for a Certificate must prove their control or ownership of the domain name before a certificate can be granted by a CA, which may be achieved by multiple methods, some of which use some elements of the RDS, some of which use the DNS, some of which use non-technical means, as set out in section 3,2,2.4 of the CA/B Baseline Requirements There are three methods that use the RDS. Method 3.2,2.4.1 is to use the RDS to confirm the applicant is the domain contact. This method may only be used if the personal identity of the domain contact has also been confirmed by methods outside the RDS (eg the methods in section 3.2.2.1 of the CA/B Baseline Requirements, or the Extended Validation equivalents, or the CA is also the registrar (see also 3.2.2..4.12)). It is to be expected that the domain contact will have consented to, and practically facilitated, the confirmation of their personal identity by means outside the RDS, if they wish to use this method, and also the CA must be able to access the domain contact data. A person identified by this means must also remain a current domain contact in order to make any certificate changes. This method requires ongoing access to domain contact personal identifying information. There may be cases where access to additional personal identifying information beyond Domain Contact name is required for disambiguation purposes, as names are not unique identifiers. Method 3.2.2.4.2 is to use Email, Fax, SMS, or Postal Mail This method requires the applicant to provide one of these forms of communication to the CA that is visible within the RDS and ascribed to a domain contact, accessible to the CA to use, and that the domain contact can access. It is not necessary that the applicant uses those means to reply to the CA, only that they are able to supply a Random Value communicated to them. Method 3.2.2.4.3 is via phone. This method requires the applicant to provide a phone number associated with the Domain Contact within the RDS, and to make that information accessible to the CA. This requires both phone information and domain contact information. This method is only effective if the information is valid and may be used to initiate a phone conversation with the domain contact. There are multiple other methods for verifying control, that we have not described in detail, as they do not use the RDS. There are a range of technical methods that rely on demonstrating control and access to either services that are run directly under that domain name (for example, mail service 3.2.2.4.4, web sites 3.2.2.4.6, TLS 3.2.2.4.9 and 3.2.2.4.10), or the DNS itself (3.2.2..4.7). It is worth noting that the only non-technical method of verification that does NOT also require information from the RDS, method 3.2.2.4.5, Domain Authorisation Document, will no longer be valid for use after August 2018. We recommend this method is ignored for purpose of working group deliberation at this point for that reason. In addition to the above, we should also note the requirements for more advanced forms of certificate, the Organisational and Extended Validation Certificate, The drafting team wishes to separate discussion of these form of certificate, as this discussion is primarily to demonstrate their inapplicability for purposes of this question within this working groups scope. Discussion of Extended Validation Certificates 1. Who associated with the domain name registration needs to be identified and/or contacted for the purpose of Domain Name Certification? Four roles are possibly needed for an Extended Validation certificate to be issues, an authorized Certificate Requester, authorized Certificate Approver, an authorized Contract Signer, and an authorized Applicant Representative These are natural persons who are either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant for that role (they may be a single person). These roles must be identified and validated by independent means to the RDS. Reference. CA/Browser Forum Guidelines For The Issuance And Management Of Extended Validation Certificates version 1.6.5, section 11.8 and 11.9 2. What is the objective achieved by identifying and/or contacting each of those entities? The purpose of an Extended Validation certificate is to identify the legal identity that controls a web site, and to enable Encrypted Communications. Reference. CA/Browser Forum Guidelines For The Issuance And Management Of Extended Validation Certificates version 1.6.5, section 2.1 and 2.1.1 Secondary purposes include establishing business legitimacy and mitigating various forms of online identity fraud (section 2.1.2), but not establishing business honesty or trustworthiness (2.1.3) 3. What might be expected of that entity with regard to the domain name? With regard to the applicant, it is expected that they are verified as a registered holder, or controller, of the Domain Name(s) to be included in the EV Certificate; (11.1.1. (2)). This must be performed via one of the methods in the CA/B Baseline Requirements section 3.2.2.4. and additional checks must be performed on domain names that utilise multiple character sets. Reference CA/Browser Forum Guidelines For The Issuance And Management Of Extended Validation Certificates version 1.6.5, section 11.7 There are additional requirements for certificates issues to .onion names, but these are not part of the Domain Name System and not relevant to this working groups scope. There are many additional requirements for Extended Validation Certificate, but that do not vary dependent on the Domain Name, and do not utilise the RDS (and are generally required to be verified by means wholly independent of the RDS), and so are outside the scope of this working group. So discussion of the requirements of 3.2.2.4 of the CA/B Baseline Requirements is relevant to Extended Validation Certificates, but the other requirements of Extended Validation certificates are outside the scope of this working group.

2 2

added Kirk Hall/ RDS drafting team 3 / Reconvening Domain Name Certification team
by Terri Agnew March 12, 2018

March 12, 2018

Hello RDS Drafting Team 3, This is to inform you Kirk Hall has been added to the drafting team. Welcome Kirk. Thank you. With kind regards, Terri --- Terri Agnew Operations Support - GNSO Lead Administrator Internet Corporation for Assigned Names and Numbers (ICANN) Email: <mailto:terri.agnew@icann.org> terri.agnew(a)icann.org Skype ID: terri.agnew.icann Find out more about the GNSO by taking our interactive courses and visiting the <https://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy -efforts.htm#newcomers> GNSO Newcomer pages Follow @GNSO on Twitter: <https://twitter.com/ICANN_GNSO> https://twitter.com/ICANN_GNSO Follow the GNSO on Facebook: <https://www.facebook.com/icanngnso/> https://www.facebook.com/icanngnso/ <http://gnso.icann.org/en/> http://gnso.icann.org/en/

4 8

Presenter for Saturday morning
by David Cake March 9, 2018

March 9, 2018

I am having travel problems, and I will be unable to be present for the Working Group meeting on Saturday morning. I would appreciate it if another member of this drafting team is able to present our discussion at the face to face meeting on saturday. I do not anticipate that this will take very long, as our findings are short and have largely already been discussed before. David

2 2

Reconvening Domain Name Certification team
by David Cake March 6, 2018

March 6, 2018

If you were on the call earlier, you would have heard that the leadership of the Next Generation RDS PDP WG have decided to reconvene the separate Drafting Teams, including the team for Domain Name Certification. We would like to take a week to prepare for discussion at the face to face meeting at iCANN 61. We would like to reopen discussion, and the new questions we would like the team to answer are: Who associated with the domain name registration needs to be identified and/or contacted for this purpose? What is the objective achieved by identifying and contacting each of those entities? What might be expected with regard to that domain name? All the teams are requested to not restrict themselves to existing data elements, but try to answer the questions conceptually and explicitly. To prep for ICANN61, it is imperative that we discuss these questions and produce output over the next week – ideally by 5 March but no later than 7 March. We know this is a short timeframe. To learn more about this assignment, please read these instructions: https://community.icann.org/download/attachments/79432608/Drafting%20Team%2… <https://community.icann.org/download/attachments/79432608/Drafting%20Team%2…> If you did not attend today’s WG call, you can catch up by reading or listening to the call recording/notes/transcript: https://community.icann.org/x/oAu8B <https://community.icann.org/x/oAu8B> We need to get started immediately — within 24 hours ideally. We may also be having some new volunteers join the team. David

3 4

DT3 job done
by David Cake Nov. 16, 2017

Nov. 16, 2017

Though some of the other Drafting Teams are not quite done yet, Drafting Team 3 has submitted its work and there is no reason to think we will be doing more at this time. So thanks for all of your contributions, especially Alex. Myself and the leadership team appreciate it. Of course see you in the main group discussion etc. David

1 0

Re: [Gnso-rds-pdp-3] [EXTERNAL] Re: finishing report
by David Cake Nov. 13, 2017

Nov. 13, 2017

I made only one major change - removing the link to the EWG definition, which I think we all agree is flawed, and I felt was redundant now. The only other change I made was turning website into web site. Thank you all for your efforts. David > On 12 Nov 2017, at 10:15 am, Feher, Kal <Kalman.Feher(a)team.neustar> wrote: > > Sorry for my delayed response, I've been traveling to IETF. > > I think the document is complete. I don't have any further changes. > > Kal Feher > > > From: "Deacon, Alex" <Alex_Deacon(a)mpaa.org <mailto:Alex_Deacon@mpaa.org>> > Date: Saturday, 11 November 2017 at 06:15 > To: Kal Feher <kalman.feher(a)team.neustar <mailto:kalman.feher@team.neustar>>, "gnso-rds-pdp-3(a)icann.org <mailto:gnso-rds-pdp-3@icann.org>" <gnso-rds-pdp-3(a)icann.org <mailto:gnso-rds-pdp-3@icann.org>>, David Cake <dave(a)davecake.net <mailto:dave@davecake.net>> > Subject: Re: [EXTERNAL] Re: [Gnso-rds-pdp-3] finishing report > > Thanks Kal. > > Apologies for the typo’s and auto-correct issues – I was in a rush to send it out. > > Anyway - Here is one more update on top of yours with a few more mods to the purpose up front. It now states. > > Purpose: > Information collected by a certificate authority to enable contact between the registrant, or a technical or administrative representative of the registrant, to assist in verifying that the identity of the certificate applicant is the same as the entity that controls the domain name. > > Alex > > > From: "Feher, Kal" <Kalman.Feher(a)team.neustar <mailto:Kalman.Feher@team.neustar>> > Date: Thursday, November 9, 2017 at 5:52 PM > To: "Deacon, Alex" <Alex_Deacon(a)mpaa.org <mailto:Alex_Deacon@mpaa.org>>, "gnso-rds-pdp-3(a)icann.org <mailto:gnso-rds-pdp-3@icann.org>" <gnso-rds-pdp-3(a)icann.org <mailto:gnso-rds-pdp-3@icann.org>>, David Cake <dave(a)davecake.net <mailto:dave@davecake.net>> > Subject: Re: [EXTERNAL] Re: [Gnso-rds-pdp-3] finishing report > > Please note that none of my emails to the subgroup mailing list have been received for some reason. > > I've made some minor edits to the purpose. I fixed up a recurring typo for "identity". I replaced domain ownership with "control". That is the term used by CAs and the baseline guidelines. Ownership is not determined in this method. Bearing in mind that certificate requests could be delegated to hosting operators. With that minor and slightly pedantic change, I think the purpose is fine. If we wanted to be really pedantic then it would be "authorised control" as it appears in the certificate guideline glossary. > > I disagree with adding the organisation field in the data elements. They are not required by Certificate Authorities and the guidelines are quite clear on this. This includes guidelines for basic certs (the domain control part of the baseline guide), organisation validated certs (domain control plus org validation from baseline guidelines) and extended validation certs (domain control from baseline plus the EV guidelines). As I stated in the f2f, the only thing the CAB forums use the RDS for is to contact the registrant/admin/tech contact to prove authorised control. RDS is not used to prove organisation identity. If a CA chose to do this, they'd actually be less secure and increase risks of fraudulent certificate validation. > > Kal Feher > Neustar Inc. > Level 8, 10 Queens Road, Melbourne, Australia VIC 3004 > Office +61 3 9866 3710 / kal.feher(a)team.neustar <mailto:kal.feher@team.neustar> / www.neustar.biz <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protect…> > > Follow Neustar: <image001.png> Facebook <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protect…> <image002.png> LinkedIn <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protect…> <image003.png> Twitter <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protect…> > The information contained in this e-mail message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this e-mail message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message. > > > From: <gnso-rds-pdp-3-bounces(a)icann.org <mailto:gnso-rds-pdp-3-bounces@icann.org>> on behalf of "Deacon, Alex" <Alex_Deacon(a)mpaa.org <mailto:Alex_Deacon@mpaa.org>> > Date: Friday, 10 November 2017 at 07:03 > To: "gnso-rds-pdp-3(a)icann.org <mailto:gnso-rds-pdp-3@icann.org>" <gnso-rds-pdp-3(a)icann.org <mailto:gnso-rds-pdp-3@icann.org>> > Subject: [EXTERNAL] Re: [Gnso-rds-pdp-3] finishing report > > Here is my “Post Abu Dhabi” update. I added a “purpose in one sentence” up top and then beefed up the data elements section to bring it in line with what other groups have done. > > Thanks! > Alex > > > From: <gnso-rds-pdp-3-bounces(a)icann.org <mailto:gnso-rds-pdp-3-bounces@icann.org>> on behalf of "Deacon, Alex" <Alex_Deacon(a)mpaa.org <mailto:Alex_Deacon@mpaa.org>> > Date: Tuesday, November 7, 2017 at 10:47 AM > To: David Cake <dave(a)davecake.net <mailto:dave@davecake.net>>, "gnso-rds-pdp-3(a)icann.org <mailto:gnso-rds-pdp-3@icann.org>" <gnso-rds-pdp-3(a)icann.org <mailto:gnso-rds-pdp-3@icann.org>> > Cc: thomascovenant <dinasolveig(a)thomascovenant.org <mailto:dinasolveig@thomascovenant.org>> > Subject: Re: [Gnso-rds-pdp-3] finishing report > > I’ll take a shot at an update and send a revision on Thursday for review. > > Aelx > > > From: <gnso-rds-pdp-3-bounces(a)icann.org <mailto:gnso-rds-pdp-3-bounces@icann.org>> on behalf of David Cake <dave(a)davecake.net <mailto:dave@davecake.net>> > Date: Tuesday, November 7, 2017 at 10:08 AM > To: "gnso-rds-pdp-3(a)icann.org <mailto:gnso-rds-pdp-3@icann.org>" <gnso-rds-pdp-3(a)icann.org <mailto:gnso-rds-pdp-3@icann.org>> > Cc: thomascovenant <dinasolveig(a)thomascovenant.org <mailto:dinasolveig@thomascovenant.org>> > Subject: [Gnso-rds-pdp-3] finishing report > > The DT3 report is due to be completed this friday. > I have not scheduled a meeting, as previous discussion suggested there were only minor changes needed and it could be performed via email. > > I have attached the report as presented - please suggest revisions and updates that you feel would make the report clearer. > > David > > > > > _______________________________________________ > Gnso-rds-pdp-3 mailing list > Gnso-rds-pdp-3(a)icann.org <mailto:Gnso-rds-pdp-3@icann.org> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.o… <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense…><image001.png><image002.png><image003.png>

2 1

Re: [Gnso-rds-pdp-3] [EXTERNAL] Re: finishing report
by Deacon, Alex Nov. 10, 2017

Nov. 10, 2017

Thanks Kal. Apologies for the typo’s and auto-correct issues – I was in a rush to send it out. Anyway - Here is one more update on top of yours with a few more mods to the purpose up front. It now states. Purpose: Information collected by a certificate authority to enable contact between the registrant, or a technical or administrative representative of the registrant, to assist in verifying that the identity of the certificate applicant is the same as the entity that controls the domain name. Alex From: "Feher, Kal" <Kalman.Feher(a)team.neustar> Date: Thursday, November 9, 2017 at 5:52 PM To: "Deacon, Alex" <Alex_Deacon(a)mpaa.org>, "gnso-rds-pdp-3(a)icann.org" <gnso-rds-pdp-3(a)icann.org>, David Cake <dave(a)davecake.net> Subject: Re: [EXTERNAL] Re: [Gnso-rds-pdp-3] finishing report Please note that none of my emails to the subgroup mailing list have been received for some reason. I've made some minor edits to the purpose. I fixed up a recurring typo for "identity". I replaced domain ownership with "control". That is the term used by CAs and the baseline guidelines. Ownership is not determined in this method. Bearing in mind that certificate requests could be delegated to hosting operators. With that minor and slightly pedantic change, I think the purpose is fine. If we wanted to be really pedantic then it would be "authorised control" as it appears in the certificate guideline glossary. I disagree with adding the organisation field in the data elements. They are not required by Certificate Authorities and the guidelines are quite clear on this. This includes guidelines for basic certs (the domain control part of the baseline guide), organisation validated certs (domain control plus org validation from baseline guidelines) and extended validation certs (domain control from baseline plus the EV guidelines). As I stated in the f2f, the only thing the CAB forums use the RDS for is to contact the registrant/admin/tech contact to prove authorised control. RDS is not used to prove organisation identity. If a CA chose to do this, they'd actually be less secure and increase risks of fraudulent certificate validation. Kal Feher Neustar Inc. Level 8, 10 Queens Road, Melbourne, Australia VIC 3004 Office +61 3 9866 3710 / kal.feher(a)team.neustar / www.neustar.biz<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.neustar…> Follow Neustar: [ttp://neunet.neustar.biz/sites/default/files/295/New%20Picture.png] Facebook<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.faceboo…> [ttp://neunet.neustar.biz/sites/default/files/295/New%20Picture%20(1)(1).png] LinkedIn<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedi…> [ttp://neunet.neustar.biz/sites/default/files/295/New%20Picture%20(2).png] Twitter<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitter…> ________________________________ The information contained in this e-mail message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this e-mail message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message. From: <gnso-rds-pdp-3-bounces(a)icann.org<mailto:gnso-rds-pdp-3-bounces@icann.org>> on behalf of "Deacon, Alex" <Alex_Deacon(a)mpaa.org<mailto:Alex_Deacon@mpaa.org>> Date: Friday, 10 November 2017 at 07:03 To: "gnso-rds-pdp-3(a)icann.org<mailto:gnso-rds-pdp-3@icann.org>" <gnso-rds-pdp-3(a)icann.org<mailto:gnso-rds-pdp-3@icann.org>> Subject: [EXTERNAL] Re: [Gnso-rds-pdp-3] finishing report Here is my “Post Abu Dhabi” update. I added a “purpose in one sentence” up top and then beefed up the data elements section to bring it in line with what other groups have done. Thanks! Alex From: <gnso-rds-pdp-3-bounces(a)icann.org<mailto:gnso-rds-pdp-3-bounces@icann.org>> on behalf of "Deacon, Alex" <Alex_Deacon(a)mpaa.org<mailto:Alex_Deacon@mpaa.org>> Date: Tuesday, November 7, 2017 at 10:47 AM To: David Cake <dave(a)davecake.net<mailto:dave@davecake.net>>, "gnso-rds-pdp-3(a)icann.org<mailto:gnso-rds-pdp-3@icann.org>" <gnso-rds-pdp-3(a)icann.org<mailto:gnso-rds-pdp-3@icann.org>> Cc: thomascovenant <dinasolveig(a)thomascovenant.org<mailto:dinasolveig@thomascovenant.org>> Subject: Re: [Gnso-rds-pdp-3] finishing report I’ll take a shot at an update and send a revision on Thursday for review. Aelx From: <gnso-rds-pdp-3-bounces(a)icann.org<mailto:gnso-rds-pdp-3-bounces@icann.org>> on behalf of David Cake <dave(a)davecake.net<mailto:dave@davecake.net>> Date: Tuesday, November 7, 2017 at 10:08 AM To: "gnso-rds-pdp-3(a)icann.org<mailto:gnso-rds-pdp-3@icann.org>" <gnso-rds-pdp-3(a)icann.org<mailto:gnso-rds-pdp-3@icann.org>> Cc: thomascovenant <dinasolveig(a)thomascovenant.org<mailto:dinasolveig@thomascovenant.org>> Subject: [Gnso-rds-pdp-3] finishing report The DT3 report is due to be completed this friday. I have not scheduled a meeting, as previous discussion suggested there were only minor changes needed and it could be performed via email. I have attached the report as presented - please suggest revisions and updates that you feel would make the report clearer. David _______________________________________________ Gnso-rds-pdp-3 mailing list Gnso-rds-pdp-3(a)icann.org<mailto:Gnso-rds-pdp-3@icann.org> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.o…<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense…>

1 0

finishing report
by David Cake Nov. 9, 2017

Nov. 9, 2017

The DT3 report is due to be completed this friday. I have not scheduled a meeting, as previous discussion suggested there were only minor changes needed and it could be performed via email. I have attached the report as presented - please suggest revisions and updates that you feel would make the report clearer. David

2 2

Any changes?
by David Cake Nov. 1, 2017

Nov. 1, 2017

Our report seemed relatively well received on Saturday, I think people appreciated that we had looked at the issues in detail. Based on feedback and questions from those in the room, do you think there are any changes we should make before the meeting on Wednesday? David

3 2

Revised document
by David Cake Oct. 28, 2017

Oct. 28, 2017

I revised the document significantly from Alex’s version, but the majority of the changes are simply to remove operational and template material (such as descriptions of timelines, etc.) I have made some changes to the group conclusions in the document, but I hope that I have not included anything not specifically on the call. Please let me know if you think any changes need to be made very quickly - other wise this draft will be sent to the working group in a few hours, David

4 3

Presenting in Abu Dhabi
by David Cake Oct. 26, 2017

Oct. 26, 2017

I will not be in Abu Dhabi. Would one you volunteer to present this groups work to the face to face meeting in Abu Dhabi? Alex, you would be best placed, but if you can’t we will need somebody. Regards David

3 3

Discussion from first meeting
by David Cake Oct. 23, 2017

Oct. 23, 2017

Thank you to those that managed to make it to our Adobe Connect meeting today, We used the document Alex supplied as our initial basis for discussions. We also looked at the CAB Forum Guidelines For The Issuance And Management Of Extended Validation Certificates https://cabforum.org/wp-content/uploads/EV-V1_6_5.pdf <https://cabforum.org/wp-content/uploads/EV-V1_6_5.pdf> We discussed the different methods of validation, etc. Some methods of certificate validation focus only on demonstrating that the certificate applicant is in control of the domain, this includes the ACME protocol used by Lets Encrypt!, and these methods use the DNS directly, but do not use the RDS at all. We agreed that we did not feel that discussing the value of various forms of validation was largely outside of our scope, and had limited value. Validation that does not require access of personally identifying information exists, but by its nature does not act as a purpose for accessing the RDS. We chose to focus on the Extended Validation certificate case. The case of Extended Validation extends beyond the DNS and is designed to identify certificate ownership by a particular legal identity, so has a clear case to access identifying data. We discussed the Guidelines in detail, and noted that it was not an absolute necessity to use information from the RDS to validate identity for an EV - while an EV required validation of domain ownership, this could be performed solely via the DNS if necessary, and while an EV required validation of identify, this did not necessarily require use of identifying information from the RDS to perform. However, identifying information in the RDS could improve the practicality and quality of validation, and was used practically by many CAs in their normal course of business and was very practical for many reasons. We discussed that consent to accessing identifying information was implicit in requesting an EV certificate. We generally did not feel that DNS Certification was a necessary purpose for collection of personally identifying data. Regular use of a domain name is possible without certification, or limited certification is possible without RDS data. But the EV Certificate case was a notable purpose for access of existing personally identifying data. Any comments, corrections, additions, or follow up? David

3 5

UPDATED AC Recording, AC Chat & Attendance from Next-Gen RDS drafting team 2- Domain Name Certification call on Thursday, 19 October 2017 23:00 UTC
by Michelle DeSmyter Oct. 20, 2017

Oct. 20, 2017

Dear all, Please find below the Adobe Connect recording, chat and attendance from the Next-Gen RDS drafting team 2 - Domain Name Certification call held on Thursday, 19 October 2017 at 23:00 UTC. Adobe Connect recording: https://participate.icann.org/p8b68sem06w/ Apologies: Arsène Tungali Attendance: Alex Deacon, David Cake, Kal Feher Staff: Michelle DeSmyter AC Chat: Michelle DeSmyter:Welcome to the GNSO Next-Gen RDS Drafting team #3: Domain Name Certification call on Thursday, 19 October 2017 at 23:00 UTC for 60 minutes. Michelle DeSmyter:Drafting teams and mailing list archives wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_… Kal Feher:no audio possible? Kal Feher:nvm. it appeared the second time I tried Kal Feher:better! Michelle DeSmyter:I uploaded the document Alex sent out and unsynced it, so you can scroll through if you would like. Kal Feher:EV requirements: https://urldefense.proofpoint.com/v2/url?u=https-3A__cabforum.org_wp-2Dcont… Kal Feher:FYI the two letsencrypt validation methods are 3.2.2.4.6 and 3.2.2.4.7 Thank you. Kind regards, Michelle DeSmyter SOAC Support GNSO/GDD Internet Corporation for Assigned Names and Numbers (ICANN) Email: michelle.desmyter(a)icann.org<mailto:michelle.desmyter@icann.org>

1 0

UPDATED AC Recording, AC Chat & Attendance from Next-Gen RDS drafting team 2 - Domain Name Certification call on Thursday, 19 October 2017 at 23:00 UTC
by Michelle DeSmyter Oct. 20, 2017

Oct. 20, 2017

Dear all, Please find below the Adobe Connect recording, chat and attendance from the Next-Gen RDS drafting team 2 - Domain Name Certification call held on Thursday, 19 October 2017 at 23:00 UTC. Adobe Connect recording: https://participate.icann.org/p8b68sem06w/ Apologies: None Attendance: Alex Deacon, David Cake, Kal Feher Staff: Michelle DeSmyter AC Chat: Michelle DeSmyter:Welcome to the GNSO Next-Gen RDS Drafting team #3: Domain Name Certification call on Thursday, 19 October 2017 at 23:00 UTC for 60 minutes. Michelle DeSmyter:Drafting teams and mailing list archives wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_… Kal Feher:no audio possible? Kal Feher:nvm. it appeared the second time I tried Kal Feher:better! Michelle DeSmyter:I uploaded the document Alex sent out and unsynced it, so you can scroll through if you would like. Kal Feher:EV requirements: https://urldefense.proofpoint.com/v2/url?u=https-3A__cabforum.org_wp-2Dcont… Kal Feher:FYI the two letsencrypt validation methods are 3.2.2.4.6 and 3.2.2.4.7 Thank you. Kind regards, Michelle DeSmyter SOAC Support GNSO/GDD Internet Corporation for Assigned Names and Numbers (ICANN) Email: michelle.desmyter(a)icann.org<mailto:michelle.desmyter@icann.org>

2 2

AC Recording, AC Chat and attendance from Next-Gen RDS Drafting Team 3 - Domain Name Certification
by Michelle DeSmyter Oct. 20, 2017

Oct. 20, 2017

Dear all, Please find below the Adobe Connect recording, chat and attendance from the Next-Gen RDS drafting team 2 - Domain Name Certification call held on Thursday, 19 October 2017 at 23:00 UTC. Adobe Connect recording: https://participate.icann.org/p8b68sem06w/ Apologies: None Attendance: Alex Deacon, David Cake, Kal Feher Staff: Michelle DeSmyter Thank you. Kind regards, Michelle DeSmyter SOAC Support GNSO/GDD Internet Corporation for Assigned Names and Numbers (ICANN) Email: michelle.desmyter(a)icann.org

1 0

The poll
by Arsène Tungali Oct. 19, 2017

Oct. 19, 2017

Hi all, The poll does not include a lot of options to allow better choice. All the available options does not work for me, i cannot make it. Hope this can be resolved, having more options to accomodate multiple time zones. Regards, Arsene ----------------- Arsène Tungali, about.me/ArseneTungali +243 993810967 GPG: 523644A0 Goma, Democratic Republic of Congo Sent from my iPhone (excuse typos)

3 2

lets get started
by David Cake Oct. 17, 2017

Oct. 17, 2017

The first meeting, unfortunately, only two of us attended, so we cancelled it. We will try for another meeting later in the week, but we can’t wait until then to get started, as our ‘m hoping to kick off discussion with this email. Our goal is to produce, over the next week and a bit, roughly two pages or so of definition of DNS Certification as a purpose for RDS data and access. We might want to start by expanding the definition very carefully, specifying the who and why at every stage. We might want to expand the use cases in detail, for example looking at the different types of DNS certification, and which data is necessary for each, and being specific about the data required. We might want to look at alternatives to accessing RDS data. I don’t think we have anyone on this call who works for a CA. The closest we probably have is some people from EFF (Jeremy’s employer) are involved in the Lets Encrypt project, and might be able to help us with some technical questions. I know some of the technical issues related to Certification a bit, but only some. We should expect that some of our work may change in detailed discussion with a CA technical expert, but that is no reason not to get started. The EWG report includes this definition, which we might want to consider as a bare minimum starting point > Tasks within the scope of this purpose include a Certification Authority (CA) issuing an X.509 certificate to a subject identified by a domain name. To accomplish this task, the user needs to confirm that the DN is registered to the certificate subject; doing so requires access to all public and gated data about the Registrant. > Which parts of that do we agree with, which deserve further consideration? David

4 3

Drafting Team #3 – Domain Name Certification
by David Cake Oct. 16, 2017

Oct. 16, 2017

Welcome. You have been selected by the RDS leadership team to serve on a drafting team to define the RDS purpose named in the subject line above. Thank you very much for volunteering to participate in this effort. Here is the list of the team members: Coordinated by: David Cake Members: Kal Feher, Alex Deacon, Carlton Samuels, Jeremy Malcolm, Arsen Tungali As you can see, this message is being sent via a dedicated mailing list that has been set up to facilitate email communications over the next two to two and half weeks. Please use the list for all of our electronic team communications. Note that this list is publicly archived. Here are the list details. Mailing list address: gnso-rds-pdp-3(a)icann.org Mailing list archive: http://mm.icann.org/pipermail/gnso-rds-pdp-3/ Attached you will find a template that outlines our tasks and provides a timeline. Please review it right away so that we can start discussions as soon as possible. We plan to have at least two teleconference calls over the next two weeks, but additional ones may be scheduled as needed. At the same time, mailing list discussion is encouraged. The first call will be scheduled on Tuesday or Wednesday, October 17 or 18. Please complete the Doodle poll linked below not later than end of day on Sunday, October 15 so that a time can be identified that best meets team member availability. https://icannorg.doodle.com/poll/pdvu9kgtksumeefk Teams were formed using results from this week’s poll which can be found on the WG wiki. Every team includes: · At least one person from each of the perspectives named in the poll wherever possible, but without assigning members to more than one team. · A mix of members who have direct experience regarding the proposed purpose and those who have little or no experience about the proposed purpose. Remember that the purpose of this work is not to make decisions but rather to facilitate communication and understanding. The team is expected to deliver a one to two-page document to the full WG that will be used in our face to face meeting on Saturday, October 28 to help all WG members understand the applicable purpose. If you have any questions, please feel free to ask them on this list. Thanks in advance for completing the Doodle Poll promptly and for participating in our discussions starting today and in the days ahead. David Cake Drafting Team Coordinator

2 1