I think we should divide our answer according to the type of certificate required. The request from the leadership is that we add clarifying information even if it does not currently require the RDS. Anyone objet to any of the below? For all certificates, including domain name certificates. - the person who need to be identified is a person who controls the domain name. - the objective achieved is proof that the request for the certificate originates from someone with control over the domain name. - this 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. The means that do use the RDS may use email, fax, SMS, postal mail or phone numbers, as described in the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates 3.2.2.4.2 and 3.2.2.4.3 I also note that for the method of Domain contact verification via a Domain Authorisation Document, verification that WHOIS data has not changed is required, but this method is not to be used after August 2018. We recommend this method is ignored for purpose of working group deliberation for that reason. For an Extended Validation certificate: - 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 validated by independent means to the RDS. - the Drafting team believes these roles, and other aspects of Extended Validation apart from the demonstrating control of the domain name, do not depend on the RDS or DNS, and so are outside the scope of the work on this working group.

On 28 Feb 2018, at 8:25 am, Feher, Kal <Kalman.Feher@team.neustar> wrote:

Hello David and fellow certifiable team members, I've had a very relaxing 3 week vacation, so I'm a little behind, but I've read through the instructions so I'll make some suggestions.

Firstly before I comment on the open questions I'd like to make an observation based on the feedback and comments we received when presenting our prior findings. Depending on their perspectives and experience, many WG members did not truly understand that we had restricted our scope to the use of registration data in the work flow of obtaining a certificate (from a CA) for a domain name. We'd also strictly followed the documented workflow agreed to by the CA/Browser forum. No independent or alternate certificate allocation workflows were considered. It is my opinion that the narrow scoping was appropriate then and remains so now. However it may be required that we continue to clarify this point in any submission we make to the WG.

Here's some thoughts on the questions: Bearing in mind that the only purpose registration data is used in the CA/Browser forum guidelines is for proof of domain control.

--=Who associated with the domain name registration needs to be identified and/or contacted for this purpose?=-- Someone who controls the domain name. A contact filling a technical or administrative role would seem to be the most appropriate. Note that direct contact is not strictly required to deliver proof of domain control and remains a single option amongst many alternatives for such proof. Therefore the answer to this question could also quite legitimately be "no one needs to be identified and/or contacted for this purpose".

--=What is the objective achieved by identifying and contacting each of those entities?=-- Proof that the request for the certificate is supported by an entity that has control of the the domain in question.

--=What might be expected with regard to that domain name?=-- I have nothing to add here.

-- Kal Feher Neustar Inc. Melbourne, Australia

From: Gnso-rds-pdp-3 <gnso-rds-pdp-3-bounces@icann.org <mailto:gnso-rds-pdp-3-bounces@icann.org>> on behalf of David Cake <dave@davecake.net <mailto:dave@davecake.net>> Date: Wednesday, 28 February 2018 at 08:57 To: "gnso-rds-pdp-3@icann.org <mailto:gnso-rds-pdp-3@icann.org>" <gnso-rds-pdp-3@icann.org <mailto:gnso-rds-pdp-3@icann.org>> Subject: [EXTERNAL] [Gnso-rds-pdp-3] Reconvening Domain Name Certification team

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%20... <https://community.icann.org/download/attachments/79432608/Drafting%20Team%20...>

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

Hi David, I do not object to any of the content. However raising contact types which are not part of the RDS and will never be sourced from the RDS even if present may lead to more confusion. Even though the text does say that these are out of scope. I don't have any alternate text and I think we can work through the confusion amongst the broader WG, but we should bear this in mind in any presentation. Also, welcome to the group Kirk! -- Kal Feher Neustar Inc. Melbourne, Australia From: David Cake <dave@davecake.net<mailto:dave@davecake.net>> Date: Tuesday, 6 March 2018 at 04:59 To: Kal Feher <kalman.feher@team.neustar<mailto:kalman.feher@team.neustar>> Cc: "gnso-rds-pdp-3@icann.org<mailto:gnso-rds-pdp-3@icann.org>" <gnso-rds-pdp-3@icann.org<mailto:gnso-rds-pdp-3@icann.org>> Subject: Re: [EXTERNAL] [Gnso-rds-pdp-3] Reconvening Domain Name Certification team I think we should divide our answer according to the type of certificate required. The request from the leadership is that we add clarifying information even if it does not currently require the RDS. Anyone objet to any of the below? For all certificates, including domain name certificates. - the person who need to be identified is a person who controls the domain name. - the objective achieved is proof that the request for the certificate originates from someone with control over the domain name. - this 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. The means that do use the RDS may use email, fax, SMS, postal mail or phone numbers, as described in the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates 3.2.2.4.2 and 3.2.2.4.3 I also note that for the method of Domain contact verification via a Domain Authorisation Document, verification that WHOIS data has not changed is required, but this method is not to be used after August 2018. We recommend this method is ignored for purpose of working group deliberation for that reason. For an Extended Validation certificate: - 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 validated by independent means to the RDS. - the Drafting team believes these roles, and other aspects of Extended Validation apart from the demonstrating control of the domain name, do not depend on the RDS or DNS, and so are outside the scope of the work on this working group. On 28 Feb 2018, at 8:25 am, Feher, Kal <Kalman.Feher@team.neustar<mailto:Kalman.Feher@team.neustar>> wrote: Hello David and fellow certifiable team members, I've had a very relaxing 3 week vacation, so I'm a little behind, but I've read through the instructions so I'll make some suggestions. Firstly before I comment on the open questions I'd like to make an observation based on the feedback and comments we received when presenting our prior findings. Depending on their perspectives and experience, many WG members did not truly understand that we had restricted our scope to the use of registration data in the work flow of obtaining a certificate (from a CA) for a domain name. We'd also strictly followed the documented workflow agreed to by the CA/Browser forum. No independent or alternate certificate allocation workflows were considered. It is my opinion that the narrow scoping was appropriate then and remains so now. However it may be required that we continue to clarify this point in any submission we make to the WG. Here's some thoughts on the questions: Bearing in mind that the only purpose registration data is used in the CA/Browser forum guidelines is for proof of domain control. --=Who associated with the domain name registration needs to be identified and/or contacted for this purpose?=-- Someone who controls the domain name. A contact filling a technical or administrative role would seem to be the most appropriate. Note that direct contact is not strictly required to deliver proof of domain control and remains a single option amongst many alternatives for such proof. Therefore the answer to this question could also quite legitimately be "no one needs to be identified and/or contacted for this purpose". --=What is the objective achieved by identifying and contacting each of those entities?=-- Proof that the request for the certificate is supported by an entity that has control of the the domain in question. --=What might be expected with regard to that domain name?=-- I have nothing to add here. -- Kal Feher Neustar Inc. Melbourne, Australia From: Gnso-rds-pdp-3 <gnso-rds-pdp-3-bounces@icann.org<mailto:gnso-rds-pdp-3-bounces@icann.org>> on behalf of David Cake <dave@davecake.net<mailto:dave@davecake.net>> Date: Wednesday, 28 February 2018 at 08:57 To: "gnso-rds-pdp-3@icann.org<mailto:gnso-rds-pdp-3@icann.org>" <gnso-rds-pdp-3@icann.org<mailto:gnso-rds-pdp-3@icann.org>> Subject: [EXTERNAL] [Gnso-rds-pdp-3] Reconvening Domain Name Certification team 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%20... 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 We need to get started immediately — within 24 hours ideally. We may also be having some new volunteers join the team. David