- 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