Discussion from first meeting
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
Thanks David, I’ll add that from what I understand we were not tasked with discussing/debating the “collection” vs. “use/access” of data – simply to flesh out the tasks supported by the purpose, the parties involved in the purpose, and the data often used to fulfill that purpose. Also, just to clarify the highlighted sentence below where I think you mis-typed. We did all agree (and did feel) that discussing the value of various forms of validation CA’s use is out of scope. Thanks! Alex From: <gnso-rds-pdp-3-bounces@icann.org> on behalf of David Cake <dave@davecake.net> Date: Thursday, October 19, 2017 at 8:39 PM To: "gnso-rds-pdp-3@icann.org" <gnso-rds-pdp-3@icann.org> Subject: [Gnso-rds-pdp-3] Discussion from first meeting 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcabforum.org%2Fwp-content%2Fuploads%2FEV-V1_6_5.pdf&data=02%7C01%7Calex_deacon%40mpaa.org%7C3b1149f5d73f495818fa08d5176c2104%7C17e50b56d5dd439b962acc7ecd9ab7fe%7C0%7C1%7C636440675548500557&sdata=KA%2Fa9v5NmAqRH4sqStLB%2BanKdlKTQ4SFOsWfMhBuf%2BM%3D&reserved=0> 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
On 21 Oct 2017, at 2:10 am, Deacon, Alex <Alex_Deacon@mpaa.org> wrote:
Thanks David,
I’ll add that from what I understand we were not tasked with discussing/debating the “collection” vs. “use/access” of data – simply to flesh out the tasks supported by the purpose, the parties involved in the purpose, and the data often used to fulfill that purpose.
I personally think that is intrinsic to our mandate to expand on the purpose statement. But I will consult.
Also, just to clarify the highlighted sentence below where I think you mis-typed. We did all agree (and did feel) that discussing the value of various forms of validation CA’s use is out of scope.
Quite correct, I mis-typed. The value and legitimacy of various types of validation is not in scope, only that they present different cases for using registration data.
Thanks! Alex
From: <gnso-rds-pdp-3-bounces@icann.org> on behalf of David Cake <dave@davecake.net> Date: Thursday, October 19, 2017 at 8:39 PM To: "gnso-rds-pdp-3@icann.org" <gnso-rds-pdp-3@icann.org> Subject: [Gnso-rds-pdp-3] Discussion from first meeting
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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcabforum.or...>
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
So generally speaking, at this point there is little/no support for adding to purpose beyond the case for EV? -Carlton ============================== *Carlton A Samuels* *Mobile: 876-818-1799Strategy, Planning, Governance, Assessment & Turnaround* ============================= On Thu, Oct 19, 2017 at 10:38 PM, David Cake <dave@davecake.net> wrote:
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
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
_______________________________________________ Gnso-rds-pdp-3 mailing list Gnso-rds-pdp-3@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-3
Hi Carlton, I wouldn’t be that specific. Org validated (OV) certs also use WHOIS if I’m not mistaken. The main point was that we don’t need to account for CA verification/validation schemes that don’t leverage whois – such as the LetsEncrypt, self signed, etc. services. Alex From: <gnso-rds-pdp-3-bounces@icann.org> on behalf of Carlton Samuels <carlton.samuels@gmail.com> Date: Sunday, October 22, 2017 at 1:44 PM To: David Cake <dave@davecake.net> Cc: "gnso-rds-pdp-3@icann.org" <gnso-rds-pdp-3@icann.org> Subject: Re: [Gnso-rds-pdp-3] Discussion from first meeting So generally speaking, at this point there is little/no support for adding to purpose beyond the case for EV? -Carlton ============================== Carlton A Samuels Mobile: 876-818-1799 Strategy, Planning, Governance, Assessment & Turnaround ============================= On Thu, Oct 19, 2017 at 10:38 PM, David Cake <dave@davecake.net<mailto:dave@davecake.net>> wrote: 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcabforum.org%2Fwp-content%2Fuploads%2FEV-V1_6_5.pdf&data=02%7C01%7Calex_deacon%40mpaa.org%7Cf55e2ef024154cc9b86f08d5198dafdf%7C17e50b56d5dd439b962acc7ecd9ab7fe%7C0%7C1%7C636443018716375551&sdata=%2FAUnVMKbV%2BwKVyM8matIUA1AbDjABhnA3AdZGKe0ssg%3D&reserved=0> 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 _______________________________________________ Gnso-rds-pdp-3 mailing list Gnso-rds-pdp-3@icann.org<mailto:Gnso-rds-pdp-3@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-3<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-rds-pdp-3&data=02%7C01%7Calex_deacon%40mpaa.org%7Cf55e2ef024154cc9b86f08d5198dafdf%7C17e50b56d5dd439b962acc7ecd9ab7fe%7C0%7C0%7C636443018716375551&sdata=LrIptwW1y8ZRGzbqu1sYJj4gP75O9%2Fp4IJKOois0g2Q%3D&reserved=0>
Yes. LetsEncrypt etc are largely irrelevant to the WG in general and the question of purpose specifically - they use the DNS, but not the RDS. But EVs are very relevant - their actual purpose is to link the domain name to identifying information. David
On 23 Oct 2017, at 11:12 pm, Deacon, Alex <Alex_Deacon@mpaa.org> wrote:
Hi Carlton,
I wouldn’t be that specific. Org validated (OV) certs also use WHOIS if I’m not mistaken. The main point was that we don’t need to account for CA verification/validation schemes that don’t leverage whois – such as the LetsEncrypt, self signed, etc. services.
Alex
From: <gnso-rds-pdp-3-bounces@icann.org> on behalf of Carlton Samuels <carlton.samuels@gmail.com> Date: Sunday, October 22, 2017 at 1:44 PM To: David Cake <dave@davecake.net> Cc: "gnso-rds-pdp-3@icann.org" <gnso-rds-pdp-3@icann.org> Subject: Re: [Gnso-rds-pdp-3] Discussion from first meeting
So generally speaking, at this point there is little/no support for adding to purpose beyond the case for EV?
-Carlton
============================== Carlton A Samuels Mobile: 876-818-1799 Strategy, Planning, Governance, Assessment & Turnaround =============================
On Thu, Oct 19, 2017 at 10:38 PM, David Cake <dave@davecake.net <mailto:dave@davecake.net>> wrote: 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcabforum.or...>
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
_______________________________________________ Gnso-rds-pdp-3 mailing list Gnso-rds-pdp-3@icann.org <mailto:Gnso-rds-pdp-3@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-3 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.or...>
participants (3)
-
Carlton Samuels -
David Cake -
Deacon, Alex