added Kirk Hall/ RDS drafting team 3 / Reconvening Domain Name Certification team
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@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/
Hi, drafting team - I'm Kirk Hall, and I work on policy and compliance issues with Certification Authority Entrust Datacard (plus I'm a recovering lawyer). Before that I was with the CA GeoTrust (acquired by Symantec) and later started the CA AffirmTrust (acquired by Entrust Datacard). I'm currently serving as Chair of the CA/Browser Forum. Marika Konings shared the drafting team memo "Domain Name Certification," and it's very good. I would just point out the WhoIs data is widely used by CAs for three different methods of domain confirmation - BR 3.2.2.4.1, .2, and .3 - and CAs and their website owner customers very much want the WhoIs information to continue to be available, as these three methods can be among the "easiest" for website owners, particularly enterprise owners with hundreds of domains. If these methods become unavailable because WhoIs-type data becomes unavailable, it will be much harder for many website owners to confirm their domains and obtain certificates to encrypt their websites - the other domain confirmation methods require active demonstrations of control of the domain like posting a unique Random Value supplied by the CA at a specific place on each of their websites, or in each of their DNS records for each domain. This will not be popular! I understand there are policy and legal reasons why Registrars/Registries may not want to display WhoIs data to the public - but would it be possible for each Registrar/Registry to "whitelist" all the commercial CAs so that they may have access to the data? How would the Registrars/Registries obtain this data? That part is easy - there are lists of CAs whose issuing "roots" are recognized as trustworthy by the major browsers - they can be found and downloaded here: http://ccadb.org/resources http://ccadb-public.secure.force.com/mozilla/AllCertificateRecordsCSVFormat So it would be easy for Registrars/Registries to download this list and make it the "whitelist" that is allowed to access the WhoIs data, even if the data is no longer available to the general public. That would serve the interests of the domain owners, who need to obtain digital certificates from CAs. Let me know if you have any questions which commercial CAs can answer. I will be leading a face-to-face meeting of the CA/Browser Forum this Wednesday-Thursday in Washington, so it would be a good time to pull in the CAs and browsers on these issues. Best regards. Kirk Hall Entrust Datacard Chair, CA/Browser Forum From: Gnso-rds-pdp-3 [mailto:gnso-rds-pdp-3-bounces@icann.org] On Behalf Of Terri Agnew Sent: Monday, March 5, 2018 3:34 PM To: gnso-rds-pdp-3@icann.org Cc: gnso-secs@icann.org Subject: [EXTERNAL][Gnso-rds-pdp-3] added Kirk Hall/ RDS drafting team 3 / Reconvening Domain Name Certification team 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: terri.agnew@icann.org<mailto:terri.agnew@icann.org> Skype ID: terri.agnew.icann Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages<https://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-...> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO Follow the GNSO on Facebook: https://www.facebook.com/icanngnso/ http://gnso.icann.org/en/
Welcome Kirk to the drafting team, and the working group. Your expertise is very welcome.
On 6 Mar 2018, at 8:52 am, Kirk Hall <Kirk.Hall@entrustdatacard.com> wrote:
Hi, drafting team – I’m Kirk Hall, and I work on policy and compliance issues with Certification Authority Entrust Datacard (plus I’m a recovering lawyer). Before that I was with the CA GeoTrust (acquired by Symantec) and later started the CA AffirmTrust (acquired by Entrust Datacard). I’m currently serving as Chair of the CA/Browser Forum.
Marika Konings shared the drafting team memo “Domain Name Certification,” and it’s very good. I would just point out the WhoIs data is widely used by CAs for three different methods of domain confirmation – BR 3.2.2.4.1, .2, and .3 – and CAs and their website owner customers very much want the WhoIs information to continue to be available, as these three methods can be among the “easiest” for website owners, particularly enterprise owners with hundreds of domains.
That is close to our understanding, that WHOIS data is one of the methods used to demonstrate domain control. Disputes in the working group have centered around issues of data exactly what constitutes legitimate data collection, and its implications. I think there is general agreement that if the data is collected for some purpose (and while it is possible that some changes may take place, it seems likely that data of at least rough equivalence will be collected), it should be possible for it to be voluntarily used for Domain Certification by those that wish it. Quite how we express that in terms of policy that appropriately translates to the GDPR etc is something we do not quite understand. It sounds as if you agree with the drafting teams point that data for other certification purposes, eg EV certificates, needs to be sourced outside the RDS/ WHOIS system in any case, and so is largely not relevant to working group discussion?
If these methods become unavailable because WhoIs-type data becomes unavailable, it will be much harder for many website owners to confirm their domains and obtain certificates to encrypt their websites – the other domain confirmation methods require active demonstrations of control of the domain like posting a unique Random Value supplied by the CA at a specific place on each of their websites, or in each of their DNS records for each domain. This will not be popular!
The various methods involving web or dns entries are notable in that they provide an alternative, but I think there is a general understanding that many people will prefer to use the BR 3.2.2.4.x methods, and this should remain possible for those that wish it. Quite what that means at each stage of the policy process is not always clear.
I understand there are policy and legal reasons why Registrars/Registries may not want to display WhoIs data to the public – but would it be possible for each Registrar/Registry to “whitelist” all the commercial CAs so that they may have access to the data?
Some system should be possible, but the general question of how we validate/ certify access has not been addressed, and we don’t plan to get into that for a while. Hopefully some fruitful discussions will take place at the face to face meeting - will you be there, Kirk? I personally think the CAs getting the information will be a relatively easy case - clearly the applicants have assented, the list of authorized CAs should be fairly uncontroversial, and if it is only the information required above that is needed, then it is a well defined list. This is much less controversial than some other data access issues we will need to address. But as I said, we aren’t quite at that point yet.
Let me know if you have any questions which commercial CAs can answer. I will be leading a face-to-face meeting of the CA/Browser Forum this Wednesday-Thursday in Washington, so it would be a good time to pull in the CAs and browsers on these issues.
Great. I think our main question at this point is essentially if any uses of WHOIS data outside the voluntary use of data for establishing domain control is needed. David
Best regards.
Kirk Hall Entrust Datacard Chair, CA/Browser Forum
From: Gnso-rds-pdp-3 [mailto:gnso-rds-pdp-3-bounces@icann.org] On Behalf Of Terri Agnew Sent: Monday, March 5, 2018 3:34 PM To: gnso-rds-pdp-3@icann.org Cc: gnso-secs@icann.org Subject: [EXTERNAL][Gnso-rds-pdp-3] added Kirk Hall/ RDS drafting team 3 / Reconvening Domain Name Certification team
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: terri.agnew@icann.org Skype ID: terri.agnew.icann
Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO Follow the GNSO on Facebook: https://www.facebook.com/icanngnso/ http://gnso.icann.org/en/
_______________________________________________ Gnso-rds-pdp-3 mailing list Gnso-rds-pdp-3@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-3
David, I’m new to this discussion, and don’t have all the context of the prior discussion. Also, I may not use the right terminology. Responses inline From: David Cake [mailto:dave@davecake.net] Sent: Monday, March 5, 2018 11:35 PM To: Kirk Hall <Kirk.Hall@entrustdatacard.com> Cc: gnso-rds-pdp-3@icann.org Subject: [EXTERNAL]Re: [Gnso-rds-pdp-3] added Kirk Hall/ RDS drafting team 3 / Reconvening Domain Name Certification team Welcome Kirk to the drafting team, and the working group. Your expertise is very welcome. On 6 Mar 2018, at 8:52 am, Kirk Hall <Kirk.Hall@entrustdatacard.com<mailto:Kirk.Hall@entrustdatacard.com>> wrote: Hi, drafting team – I’m Kirk Hall, and I work on policy and compliance issues with Certification Authority Entrust Datacard (plus I’m a recovering lawyer). Before that I was with the CA GeoTrust (acquired by Symantec) and later started the CA AffirmTrust (acquired by Entrust Datacard). I’m currently serving as Chair of the CA/Browser Forum. Marika Konings shared the drafting team memo “Domain Name Certification,” and it’s very good. I would just point out the WhoIs data is widely used by CAs for three different methods of domain confirmation – BR 3.2.2.4.1, .2, and .3 – and CAs and their website owner customers very much want the WhoIs information to continue to be available, as these three methods can be among the “easiest” for website owners, particularly enterprise owners with hundreds of domains. That is close to our understanding, that WHOIS data is one of the methods used to demonstrate domain control. Disputes in the working group have centered around issues of data exactly what constitutes legitimate data collection, and its implications. As CAs, we have no position on what data collection is “legitimate” – but we view the WhoIs record is like an auto registry system or real estate registry system – it is intended to show (1) ownership (with enough information to disambiguate if there ar 5 “David Cakes” in your city – so address and phone number help here, (2) means of contacting the owner for a valid purpose (e.g., a complaint if the registered car was part of an auto accident, an offer to buy the registered house from the owner, or a lawsuit against the registered domain owner if libelous information was posted on the site). In other parts of society, the gathering of ownership and contact information is generally viewed as legitimate as part of everyday commerce. For a domain owner, listing ownership and contact information in the WhoIs record is a normal part of doing other transactions that are beneficial to the domain owner, such as ordering a digital certificate to encrypt your website. I think there is general agreement that if the data is collected for some purpose (and while it is possible that some changes may take place, it seems likely that data of at least rough equivalence will be collected), it should be possible for it to be voluntarily used for Domain Certification by those that wish it. That makes sense – but in the rest of the world, there may ALSO be a reason why the public can see the information, and don’t have to get the owner’s permission to see it (for example, who owns the house next door to yours if the house is sliding down the hill and you need to ready the home owner.) If could be reasonable to have a rule set for domains that allows the domain owner to approve release of ownership/contact information on a case by case basis, but it’s likely a system like that will be ignored by most domain owners and they will not respond to a valid and beneficial request for access to the information (e.g., to allow a CA to issue a cert at the domain owner’s request) Quite how we express that in terms of policy that appropriately translates to the GDPR etc is something we do not quite understand. Does the GDPR allow exceptions to privacy when reasonably necessary for the provision of goods and services to the data owner? It sounds as if you agree with the drafting teams point that data for other certification purposes, eg EV certificates, needs to be sourced outside the RDS/ WHOIS system in any case, and so is largely not relevant to working group discussion? On the provision of EV certificates, most of the identity information comes from third party data sources (state and national corporate registry agencies (Secretary of State’s records, Companies House UK), private corporate data sources like Hoover’s/Dun & Bradstreet, etc.) However, EV certificates also require confirmation of domain ownership or control for domains to be included in the certificate, which defaults back to the 10 methods for domain validation – which also includes access to WhoIs data for some of the validation methods. If these methods become unavailable because WhoIs-type data becomes unavailable, it will be much harder for many website owners to confirm their domains and obtain certificates to encrypt their websites – the other domain confirmation methods require active demonstrations of control of the domain like posting a unique Random Value supplied by the CA at a specific place on each of their websites, or in each of their DNS records for each domain. This will not be popular! The various methods involving web or dns entries are notable in that they provide an alternative, but I think there is a general understanding that many people will prefer to use the BR 3.2.2.4.x methods, and this should remain possible for those that wish it. Quite what that means at each stage of the policy process is not always clear. Yes, that is correct. Proving control of a domain by making an agreed upon change to the website is Method 6 (BR 3.2.2.4.6), and by making a change to the DNS record is Method 7 (BR 3.2.2.4.7). But other methods, like Methods 1, 2, and 3 require access to WhoIs records, and is generally easier for the domain owner to complete. In some companies, the person who buys a certificate for the website is not the same person who controls the webpages or who controls the DNS records, and it can be hard to coordinate within the company if Methods 6 or 7 are used. I understand there are policy and legal reasons why Registrars/Registries may not want to display WhoIs data to the public – but would it be possible for each Registrar/Registry to “whitelist” all the commercial CAs so that they may have access to the data? Some system should be possible, but the general question of how we validate/ certify access has not been addressed, and we don’t plan to get into that for a while. Hopefully some fruitful discussions will take place at the face to face meeting - will you be there, Kirk? I would recommend that a standard form of access agreement (giving CAs access to WhoIs data of Registrars and Registries) be created, to be used on an optional basis by registrars and registries to set the terms and conditions for access to the data. This could include terms prohibiting the CA from mining the data and reselling it, etc. It might even be possible for the CA/Browser Forum to adopt “Standard Terms and Conditions for access to WhoIs Data by Certification Authorizes” in the Forum’s Baseline Requirements document (non-mandatory), in consultation with ICANN, so that participating registrars and registries can simply make a statement “We are hereby giving access to our WhoIs data to the Certification Authorities listed here (ccadb.org list) subject to the Standard Terms and Conditions found here (link to standard document in CA/Browser Forum Baseline Requirements) – in that way, the registrars/registries would not have to come up with their own legal terms, and would not have to sign an agreement one-by-one with each CA in the world. If ICANN is interested in that approach for access to WhoIs data, the Forum can work on it. I personally think the CAs getting the information will be a relatively easy case - clearly the applicants have assented, the list of authorized CAs should be fairly uncontroversial, and if it is only the information required above that is needed, then it is a well defined list. This is much less controversial than some other data access issues we will need to address. But as I said, we aren’t quite at that point yet. Let me know if you have any questions which commercial CAs can answer. I will be leading a face-to-face meeting of the CA/Browser Forum this Wednesday-Thursday in Washington, so it would be a good time to pull in the CAs and browsers on these issues. Great. I think our main question at this point is essentially if any uses of WHOIS data outside the voluntary use of data for establishing domain control is needed. Just one slight point here – in most cases we use WhoIs data to prove control, but for certificates that contain identity data also, we use the WhoIs data to link the proof of domain control to a proven identity – so we prove Foo Corporation exists at a location, and then we prove foo.com is owned by Foo Corporation before putting it in the OV or EV certificate. David Best regards. Kirk Hall Entrust Datacard Chair, CA/Browser Forum From: Gnso-rds-pdp-3 [mailto:gnso-rds-pdp-3-bounces@icann.org] On Behalf Of Terri Agnew Sent: Monday, March 5, 2018 3:34 PM To: gnso-rds-pdp-3@icann.org<mailto:gnso-rds-pdp-3@icann.org> Cc: gnso-secs@icann.org<mailto:gnso-secs@icann.org> Subject: [EXTERNAL][Gnso-rds-pdp-3] added Kirk Hall/ RDS drafting team 3 / Reconvening Domain Name Certification team 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: terri.agnew@icann.org<mailto:terri.agnew@icann.org> Skype ID: terri.agnew.icann Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages<https://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-...> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO Follow the GNSO on Facebook: https://www.facebook.com/icanngnso/ http://gnso.icann.org/en/ _______________________________________________ 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
Kirk, can you expand on your last point regarding the linking of identity data via Whois? I'm not as familiar with the CAB requirements as you are, but I can't find any reference to using Whois for proof of identity or matching identity. We know that OV and EV certs can be issued to domains with fully private whois, so is this matching something that some CAs do opportunistically? If such a match were allowed by the CAB guidelines, as someone intimately familiar with the Whois data set and its authenticity, I'd strongly recommend against using the data this way. To clarify what we have articulated in the past, we've said that the certification process does not require the collection of registration data, but it is most certainly a legitimate use of such data if collected. Due to the diversity of experience within the broader working group we need to be a little pedantic on the differences between collection purposes and consumption purposes. So your suggestions regarding access agreements are entirely appropriate and aligned with what this group has interpreted as legitimate use of the collected data. <- the actual details of such access will be discussed much later in this working group. -- 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 Kirk Hall <Kirk.Hall@entrustdatacard.com<mailto:Kirk.Hall@entrustdatacard.com>> Date: Wednesday, 7 March 2018 at 04:02 To: David Cake <dave@davecake.net<mailto:dave@davecake.net>> 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: [Gnso-rds-pdp-3] [EXTERNAL]Re: added Kirk Hall/ RDS drafting team 3 / Reconvening Domain Name Certification team David, I’m new to this discussion, and don’t have all the context of the prior discussion. Also, I may not use the right terminology. Responses inline From: David Cake [mailto:dave@davecake.net] Sent: Monday, March 5, 2018 11:35 PM To: Kirk Hall <Kirk.Hall@entrustdatacard.com<mailto:Kirk.Hall@entrustdatacard.com>> Cc: gnso-rds-pdp-3@icann.org<mailto:gnso-rds-pdp-3@icann.org> Subject: [EXTERNAL]Re: [Gnso-rds-pdp-3] added Kirk Hall/ RDS drafting team 3 / Reconvening Domain Name Certification team Welcome Kirk to the drafting team, and the working group. Your expertise is very welcome. On 6 Mar 2018, at 8:52 am, Kirk Hall <Kirk.Hall@entrustdatacard.com<mailto:Kirk.Hall@entrustdatacard.com>> wrote: Hi, drafting team – I’m Kirk Hall, and I work on policy and compliance issues with Certification Authority Entrust Datacard (plus I’m a recovering lawyer). Before that I was with the CA GeoTrust (acquired by Symantec) and later started the CA AffirmTrust (acquired by Entrust Datacard). I’m currently serving as Chair of the CA/Browser Forum. Marika Konings shared the drafting team memo “Domain Name Certification,” and it’s very good. I would just point out the WhoIs data is widely used by CAs for three different methods of domain confirmation – BR 3.2.2.4.1, .2, and .3 – and CAs and their website owner customers very much want the WhoIs information to continue to be available, as these three methods can be among the “easiest” for website owners, particularly enterprise owners with hundreds of domains. That is close to our understanding, that WHOIS data is one of the methods used to demonstrate domain control. Disputes in the working group have centered around issues of data exactly what constitutes legitimate data collection, and its implications. As CAs, we have no position on what data collection is “legitimate” – but we view the WhoIs record is like an auto registry system or real estate registry system – it is intended to show (1) ownership (with enough information to disambiguate if there ar 5 “David Cakes” in your city – so address and phone number help here, (2) means of contacting the owner for a valid purpose (e.g., a complaint if the registered car was part of an auto accident, an offer to buy the registered house from the owner, or a lawsuit against the registered domain owner if libelous information was posted on the site). In other parts of society, the gathering of ownership and contact information is generally viewed as legitimate as part of everyday commerce. For a domain owner, listing ownership and contact information in the WhoIs record is a normal part of doing other transactions that are beneficial to the domain owner, such as ordering a digital certificate to encrypt your website. I think there is general agreement that if the data is collected for some purpose (and while it is possible that some changes may take place, it seems likely that data of at least rough equivalence will be collected), it should be possible for it to be voluntarily used for Domain Certification by those that wish it. That makes sense – but in the rest of the world, there may ALSO be a reason why the public can see the information, and don’t have to get the owner’s permission to see it (for example, who owns the house next door to yours if the house is sliding down the hill and you need to ready the home owner.) If could be reasonable to have a rule set for domains that allows the domain owner to approve release of ownership/contact information on a case by case basis, but it’s likely a system like that will be ignored by most domain owners and they will not respond to a valid and beneficial request for access to the information (e.g., to allow a CA to issue a cert at the domain owner’s request) Quite how we express that in terms of policy that appropriately translates to the GDPR etc is something we do not quite understand. Does the GDPR allow exceptions to privacy when reasonably necessary for the provision of goods and services to the data owner? It sounds as if you agree with the drafting teams point that data for other certification purposes, eg EV certificates, needs to be sourced outside the RDS/ WHOIS system in any case, and so is largely not relevant to working group discussion? On the provision of EV certificates, most of the identity information comes from third party data sources (state and national corporate registry agencies (Secretary of State’s records, Companies House UK), private corporate data sources like Hoover’s/Dun & Bradstreet, etc.) However, EV certificates also require confirmation of domain ownership or control for domains to be included in the certificate, which defaults back to the 10 methods for domain validation – which also includes access to WhoIs data for some of the validation methods. If these methods become unavailable because WhoIs-type data becomes unavailable, it will be much harder for many website owners to confirm their domains and obtain certificates to encrypt their websites – the other domain confirmation methods require active demonstrations of control of the domain like posting a unique Random Value supplied by the CA at a specific place on each of their websites, or in each of their DNS records for each domain. This will not be popular! The various methods involving web or dns entries are notable in that they provide an alternative, but I think there is a general understanding that many people will prefer to use the BR 3.2.2.4.x methods, and this should remain possible for those that wish it. Quite what that means at each stage of the policy process is not always clear. Yes, that is correct. Proving control of a domain by making an agreed upon change to the website is Method 6 (BR 3.2.2.4.6), and by making a change to the DNS record is Method 7 (BR 3.2.2.4.7). But other methods, like Methods 1, 2, and 3 require access to WhoIs records, and is generally easier for the domain owner to complete. In some companies, the person who buys a certificate for the website is not the same person who controls the webpages or who controls the DNS records, and it can be hard to coordinate within the company if Methods 6 or 7 are used. I understand there are policy and legal reasons why Registrars/Registries may not want to display WhoIs data to the public – but would it be possible for each Registrar/Registry to “whitelist” all the commercial CAs so that they may have access to the data? Some system should be possible, but the general question of how we validate/ certify access has not been addressed, and we don’t plan to get into that for a while. Hopefully some fruitful discussions will take place at the face to face meeting - will you be there, Kirk? I would recommend that a standard form of access agreement (giving CAs access to WhoIs data of Registrars and Registries) be created, to be used on an optional basis by registrars and registries to set the terms and conditions for access to the data. This could include terms prohibiting the CA from mining the data and reselling it, etc. It might even be possible for the CA/Browser Forum to adopt “Standard Terms and Conditions for access to WhoIs Data by Certification Authorizes” in the Forum’s Baseline Requirements document (non-mandatory), in consultation with ICANN, so that participating registrars and registries can simply make a statement “We are hereby giving access to our WhoIs data to the Certification Authorities listed here (ccadb.org list) subject to the Standard Terms and Conditions found here (link to standard document in CA/Browser Forum Baseline Requirements) – in that way, the registrars/registries would not have to come up with their own legal terms, and would not have to sign an agreement one-by-one with each CA in the world. If ICANN is interested in that approach for access to WhoIs data, the Forum can work on it. I personally think the CAs getting the information will be a relatively easy case - clearly the applicants have assented, the list of authorized CAs should be fairly uncontroversial, and if it is only the information required above that is needed, then it is a well defined list. This is much less controversial than some other data access issues we will need to address. But as I said, we aren’t quite at that point yet. Let me know if you have any questions which commercial CAs can answer. I will be leading a face-to-face meeting of the CA/Browser Forum this Wednesday-Thursday in Washington, so it would be a good time to pull in the CAs and browsers on these issues. Great. I think our main question at this point is essentially if any uses of WHOIS data outside the voluntary use of data for establishing domain control is needed. Just one slight point here – in most cases we use WhoIs data to prove control, but for certificates that contain identity data also, we use the WhoIs data to link the proof of domain control to a proven identity – so we prove Foo Corporation exists at a location, and then we prove foo.com is owned by Foo Corporation before putting it in the OV or EV certificate. David Best regards. Kirk Hall Entrust Datacard Chair, CA/Browser Forum From: Gnso-rds-pdp-3 [mailto:gnso-rds-pdp-3-bounces@icann.org] On Behalf Of Terri Agnew Sent: Monday, March 5, 2018 3:34 PM To: gnso-rds-pdp-3@icann.org<mailto:gnso-rds-pdp-3@icann.org> Cc: gnso-secs@icann.org<mailto:gnso-secs@icann.org> Subject: [EXTERNAL][Gnso-rds-pdp-3] added Kirk Hall/ RDS drafting team 3 / Reconvening Domain Name Certification team 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: terri.agnew@icann.org<mailto:terri.agnew@icann.org> Skype ID: terri.agnew.icann Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_gn...> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGNSO&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=r-Nirn4kOYGkwbVx0VsP9wXIoGGzhrrchbSexWZfRoA&m=QDLdE7GSRvT2PTOhOMzt1I0noe5XUB5ngFGMmfm3lPA&s=02D65xo3ZOtO04quRILzuxfhKuEQQYPcR7SuU-_ok6I&e=> Follow the GNSO on Facebook: https://www.facebook.com/icanngnso/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_icanngnso_&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=r-Nirn4kOYGkwbVx0VsP9wXIoGGzhrrchbSexWZfRoA&m=QDLdE7GSRvT2PTOhOMzt1I0noe5XUB5ngFGMmfm3lPA&s=8yO1ZAfI1tFbgEHDfdOg9G1B2SJv7XputxVTnr-4kLo&e=> http://gnso.icann.org/en/<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=r-Nirn4kOYGkwbVx0VsP9wXIoGGzhrrchbSexWZfRoA&m=QDLdE7GSRvT2PTOhOMzt1I0noe5XUB5ngFGMmfm3lPA&s=GIXM-hU-TQOBHH0He_j2DfjT6L32vu5UTZcscRXO4CY&e=> _______________________________________________ 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://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Drds-2Dpdp-2D3&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=r-Nirn4kOYGkwbVx0VsP9wXIoGGzhrrchbSexWZfRoA&m=QDLdE7GSRvT2PTOhOMzt1I0noe5XUB5ngFGMmfm3lPA&s=7M6r9txJNgWZ7AQPV71SEZktvsiYEZDP2twT89rXsQY&e=>
On 9 Mar 2018, at 5:10 am, Feher, Kal <Kalman.Feher@team.neustar> wrote:
Kirk, can you expand on your last point regarding the linking of identity data via Whois? I'm not as familiar with the CAB requirements as you are, but I can't find any reference to using Whois for proof of identity or matching identity.
I think linking identity data vis WHOIS refers to method 3.2,2.4.1 - basically, if a domain contact is identified as a particular person, and you have also verified the identity of that person by other external means (eg sighted government issued ID).
We know that OV and EV certs can be issued to domains with fully private whois, so is this matching something that some CAs do opportunistically?
Note that one way OV and EV certs can be issued to domain with fully private WHOIS will be when the CA is also the Registrar, and possibly also the privacy provider, and so has access to information that is not public. This is perfectly legit by the guidelines, method 3.2.2.4.12. David
If such a match were allowed by the CAB guidelines, as someone intimately familiar with the Whois data set and its authenticity, I'd strongly recommend against using the data this way.
To clarify what we have articulated in the past, we've said that the certification process does not require the collection of registration data, but it is most certainly a legitimate use of such data if collected. Due to the diversity of experience within the broader working group we need to be a little pedantic on the differences between collection purposes and consumption purposes. So your suggestions regarding access agreements are entirely appropriate and aligned with what this group has interpreted as legitimate use of the collected data. <- the actual details of such access will be discussed much later in this working group. -- 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 Kirk Hall <Kirk.Hall@entrustdatacard.com <mailto:Kirk.Hall@entrustdatacard.com>> Date: Wednesday, 7 March 2018 at 04:02 To: David Cake <dave@davecake.net <mailto:dave@davecake.net>> 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: [Gnso-rds-pdp-3] [EXTERNAL]Re: added Kirk Hall/ RDS drafting team 3 / Reconvening Domain Name Certification team
David, I’m new to this discussion, and don’t have all the context of the prior discussion. Also, I may not use the right terminology.
Responses inline
From: David Cake [mailto:dave@davecake.net <mailto:dave@davecake.net>] Sent: Monday, March 5, 2018 11:35 PM To: Kirk Hall <Kirk.Hall@entrustdatacard.com <mailto:Kirk.Hall@entrustdatacard.com>> Cc: gnso-rds-pdp-3@icann.org <mailto:gnso-rds-pdp-3@icann.org> Subject: [EXTERNAL]Re: [Gnso-rds-pdp-3] added Kirk Hall/ RDS drafting team 3 / Reconvening Domain Name Certification team
Welcome Kirk to the drafting team, and the working group. Your expertise is very welcome.
On 6 Mar 2018, at 8:52 am, Kirk Hall <Kirk.Hall@entrustdatacard.com <mailto:Kirk.Hall@entrustdatacard.com>> wrote:
Hi, drafting team – I’m Kirk Hall, and I work on policy and compliance issues with Certification Authority Entrust Datacard (plus I’m a recovering lawyer). Before that I was with the CA GeoTrust (acquired by Symantec) and later started the CA AffirmTrust (acquired by Entrust Datacard). I’m currently serving as Chair of the CA/Browser Forum.
Marika Konings shared the drafting team memo “Domain Name Certification,” and it’s very good. I would just point out the WhoIs data is widely used by CAs for three different methods of domain confirmation – BR 3.2.2.4.1, .2, and .3 – and CAs and their website owner customers very much want the WhoIs information to continue to be available, as these three methods can be among the “easiest” for website owners, particularly enterprise owners with hundreds of domains.
That is close to our understanding, that WHOIS data is one of the methods used to demonstrate domain control. Disputes in the working group have centered around issues of data exactly what constitutes legitimate data collection, and its implications. As CAs, we have no position on what data collection is “legitimate” – but we view the WhoIs record is like an auto registry system or real estate registry system – it is intended to show (1) ownership (with enough information to disambiguate if there ar 5 “David Cakes” in your city – so address and phone number help here, (2) means of contacting the owner for a valid purpose (e.g., a complaint if the registered car was part of an auto accident, an offer to buy the registered house from the owner, or a lawsuit against the registered domain owner if libelous information was posted on the site). In other parts of society, the gathering of ownership and contact information is generally viewed as legitimate as part of everyday commerce. For a domain owner, listing ownership and contact information in the WhoIs record is a normal part of doing other transactions that are beneficial to the domain owner, such as ordering a digital certificate to encrypt your website. I think there is general agreement that if the data is collected for some purpose (and while it is possible that some changes may take place, it seems likely that data of at least rough equivalence will be collected), it should be possible for it to be voluntarily used for Domain Certification by those that wish it. That makes sense – but in the rest of the world, there may ALSO be a reason why the public can see the information, and don’t have to get the owner’s permission to see it (for example, who owns the house next door to yours if the house is sliding down the hill and you need to ready the home owner.) If could be reasonable to have a rule set for domains that allows the domain owner to approve release of ownership/contact information on a case by case basis, but it’s likely a system like that will be ignored by most domain owners and they will not respond to a valid and beneficial request for access to the information (e.g., to allow a CA to issue a cert at the domain owner’s request) Quite how we express that in terms of policy that appropriately translates to the GDPR etc is something we do not quite understand. Does the GDPR allow exceptions to privacy when reasonably necessary for the provision of goods and services to the data owner?
It sounds as if you agree with the drafting teams point that data for other certification purposes, eg EV certificates, needs to be sourced outside the RDS/ WHOIS system in any case, and so is largely not relevant to working group discussion? On the provision of EV certificates, most of the identity information comes from third party data sources (state and national corporate registry agencies (Secretary of State’s records, Companies House UK), private corporate data sources like Hoover’s/Dun & Bradstreet, etc.) However, EV certificates also require confirmation of domain ownership or control for domains to be included in the certificate, which defaults back to the 10 methods for domain validation – which also includes access to WhoIs data for some of the validation methods.
If these methods become unavailable because WhoIs-type data becomes unavailable, it will be much harder for many website owners to confirm their domains and obtain certificates to encrypt their websites – the other domain confirmation methods require active demonstrations of control of the domain like posting a unique Random Value supplied by the CA at a specific place on each of their websites, or in each of their DNS records for each domain. This will not be popular!
The various methods involving web or dns entries are notable in that they provide an alternative, but I think there is a general understanding that many people will prefer to use the BR 3.2.2.4.x methods, and this should remain possible for those that wish it. Quite what that means at each stage of the policy process is not always clear. Yes, that is correct. Proving control of a domain by making an agreed upon change to the website is Method 6 (BR 3.2.2.4.6), and by making a change to the DNS record is Method 7 (BR 3.2.2.4.7). But other methods, like Methods 1, 2, and 3 require access to WhoIs records, and is generally easier for the domain owner to complete. In some companies, the person who buys a certificate for the website is not the same person who controls the webpages or who controls the DNS records, and it can be hard to coordinate within the company if Methods 6 or 7 are used.
I understand there are policy and legal reasons why Registrars/Registries may not want to display WhoIs data to the public – but would it be possible for each Registrar/Registry to “whitelist” all the commercial CAs so that they may have access to the data?
Some system should be possible, but the general question of how we validate/ certify access has not been addressed, and we don’t plan to get into that for a while. Hopefully some fruitful discussions will take place at the face to face meeting - will you be there, Kirk? I would recommend that a standard form of access agreement (giving CAs access to WhoIs data of Registrars and Registries) be created, to be used on an optional basis by registrars and registries to set the terms and conditions for access to the data. This could include terms prohibiting the CA from mining the data and reselling it, etc. It might even be possible for the CA/Browser Forum to adopt “Standard Terms and Conditions for access to WhoIs Data by Certification Authorizes” in the Forum’s Baseline Requirements document (non-mandatory), in consultation with ICANN, so that participating registrars and registries can simply make a statement “We are hereby giving access to our WhoIs data to the Certification Authorities listed here (ccadb.org list) subject to the Standard Terms and Conditions found here (link to standard document in CA/Browser Forum Baseline Requirements) – in that way, the registrars/registries would not have to come up with their own legal terms, and would not have to sign an agreement one-by-one with each CA in the world. If ICANN is interested in that approach for access to WhoIs data, the Forum can work on it. I personally think the CAs getting the information will be a relatively easy case - clearly the applicants have assented, the list of authorized CAs should be fairly uncontroversial, and if it is only the information required above that is needed, then it is a well defined list. This is much less controversial than some other data access issues we will need to address. But as I said, we aren’t quite at that point yet.
Let me know if you have any questions which commercial CAs can answer. I will be leading a face-to-face meeting of the CA/Browser Forum this Wednesday-Thursday in Washington, so it would be a good time to pull in the CAs and browsers on these issues.
Great. I think our main question at this point is essentially if any uses of WHOIS data outside the voluntary use of data for establishing domain control is needed. Just one slight point here – in most cases we use WhoIs data to prove control, but for certificates that contain identity data also, we use the WhoIs data to link the proof of domain control to a proven identity – so we prove Foo Corporation exists at a location, and then we prove foo.com is owned by Foo Corporation before putting it in the OV or EV certificate.
David
Best regards.
Kirk Hall Entrust Datacard Chair, CA/Browser Forum
From: Gnso-rds-pdp-3 [mailto:gnso-rds-pdp-3-bounces@icann.org <mailto:gnso-rds-pdp-3-bounces@icann.org>] On Behalf Of Terri Agnew Sent: Monday, March 5, 2018 3:34 PM To: gnso-rds-pdp-3@icann.org <mailto:gnso-rds-pdp-3@icann.org> Cc: gnso-secs@icann.org <mailto:gnso-secs@icann.org> Subject: [EXTERNAL][Gnso-rds-pdp-3] added Kirk Hall/ RDS drafting team 3 / Reconvening Domain Name Certification team
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: terri.agnew@icann.org <mailto:terri.agnew@icann.org> Skype ID: terri.agnew.icann
Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_gn...> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGNS...> Follow the GNSO on Facebook: https://www.facebook.com/icanngnso/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_icanng...> http://gnso.icann.org/en/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_&d=DwM...>
_______________________________________________ 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://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li...>
Responses inline. From: Feher, Kal [mailto:Kalman.Feher@team.neustar] Sent: Thursday, March 8, 2018 1:10 PM To: Kirk Hall <Kirk.Hall@entrustdatacard.com>; David Cake <dave@davecake.net> Cc: gnso-rds-pdp-3@icann.org Subject: Re: [Gnso-rds-pdp-3] [EXTERNAL]Re: added Kirk Hall/ RDS drafting team 3 / Reconvening Domain Name Certification team Kirk, can you expand on your last point regarding the linking of identity data via Whois? I'm not as familiar with the CAB requirements as you are, but I can't find any reference to using Whois for proof of identity or matching identity. We know that OV and EV certs can be issued to domains with fully private whois, so is this matching something that some CAs do opportunistically? If such a match were allowed by the CAB guidelines, as someone intimately familiar with the Whois data set and its authenticity, I'd strongly recommend against using the data this way. [KH] I think I was unclear on this point - the process basically works in the opposite direction. Under Method 1, the CA first establishes the customer's identity under BR 3.2.1 (for OV certs) or the EV Guidelines (for EV certs), not using WhoIs data, and also confirms it's communicating with the confirmed organization by using a Reliable Method of Communication under BR 3.2.5 (so not talking to a hacker imitating the real organization). Typically this is done by finding the organization's phone number through a reliable third party data source like Hoovers/Dun & Bradstreet, then calling the Applicant Representative (the person ordering the cert) through that main switchboard number to confirm s/he is with the organization. Once that is done, then the customer asks for a cert for "example.com" and the CA looks up the Registrant name and address in WhoIs - if it's the same as the organization previously identified without using any WhoIs data, the CA can issue for the domain. (CAs generally will take additional steps to disambiguate the organization if there is an issue of confusion about the organization listed as Registrant in WhoIs - in the rare and unlikely case that there are two "real" organizations with the same or confusingly similar names. Often the address is the key factor for this.). I attach a presentation given last week on how Method 1 is typically used. We never use WhoIs to prove the identity of an organization - instead, we use other methods for that, and then look at the WhoIs Registrant data to see if the confirmed organization owns the domain and can request the cert. I should point out that Method 1 is the first method listed because it has been used by CAs since the 1990s with no reported cases of misissuance. In fact, when the EV Guidelines were first introduced in around 2008, it only allowed EV certs to be issued to the Registrant of the domain in WhoIs, and practical demonstration methods were only allowed if the WhoIs data was unavailable. To clarify what we have articulated in the past, we've said that the certification process does not require the collection of registration data, but it is most certainly a legitimate use of such data if collected. Due to the diversity of experience within the broader working group we need to be a little pedantic on the differences between collection purposes and consumption purposes. So your suggestions regarding access agreements are entirely appropriate and aligned with what this group has interpreted as legitimate use of the collected data. <- the actual details of such access will be discussed much later in this working group. -- 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 Kirk Hall <Kirk.Hall@entrustdatacard.com<mailto:Kirk.Hall@entrustdatacard.com>> Date: Wednesday, 7 March 2018 at 04:02 To: David Cake <dave@davecake.net<mailto:dave@davecake.net>> 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: [Gnso-rds-pdp-3] [EXTERNAL]Re: added Kirk Hall/ RDS drafting team 3 / Reconvening Domain Name Certification team David, I'm new to this discussion, and don't have all the context of the prior discussion. Also, I may not use the right terminology. Responses inline From: David Cake [mailto:dave@davecake.net] Sent: Monday, March 5, 2018 11:35 PM To: Kirk Hall <Kirk.Hall@entrustdatacard.com<mailto:Kirk.Hall@entrustdatacard.com>> Cc: gnso-rds-pdp-3@icann.org<mailto:gnso-rds-pdp-3@icann.org> Subject: [EXTERNAL]Re: [Gnso-rds-pdp-3] added Kirk Hall/ RDS drafting team 3 / Reconvening Domain Name Certification team Welcome Kirk to the drafting team, and the working group. Your expertise is very welcome. On 6 Mar 2018, at 8:52 am, Kirk Hall <Kirk.Hall@entrustdatacard.com<mailto:Kirk.Hall@entrustdatacard.com>> wrote: Hi, drafting team - I'm Kirk Hall, and I work on policy and compliance issues with Certification Authority Entrust Datacard (plus I'm a recovering lawyer). Before that I was with the CA GeoTrust (acquired by Symantec) and later started the CA AffirmTrust (acquired by Entrust Datacard). I'm currently serving as Chair of the CA/Browser Forum. Marika Konings shared the drafting team memo "Domain Name Certification," and it's very good. I would just point out the WhoIs data is widely used by CAs for three different methods of domain confirmation - BR 3.2.2.4.1, .2, and .3 - and CAs and their website owner customers very much want the WhoIs information to continue to be available, as these three methods can be among the "easiest" for website owners, particularly enterprise owners with hundreds of domains. That is close to our understanding, that WHOIS data is one of the methods used to demonstrate domain control. Disputes in the working group have centered around issues of data exactly what constitutes legitimate data collection, and its implications. As CAs, we have no position on what data collection is "legitimate" - but we view the WhoIs record is like an auto registry system or real estate registry system - it is intended to show (1) ownership (with enough information to disambiguate if there ar 5 "David Cakes" in your city - so address and phone number help here, (2) means of contacting the owner for a valid purpose (e.g., a complaint if the registered car was part of an auto accident, an offer to buy the registered house from the owner, or a lawsuit against the registered domain owner if libelous information was posted on the site). In other parts of society, the gathering of ownership and contact information is generally viewed as legitimate as part of everyday commerce. For a domain owner, listing ownership and contact information in the WhoIs record is a normal part of doing other transactions that are beneficial to the domain owner, such as ordering a digital certificate to encrypt your website. I think there is general agreement that if the data is collected for some purpose (and while it is possible that some changes may take place, it seems likely that data of at least rough equivalence will be collected), it should be possible for it to be voluntarily used for Domain Certification by those that wish it. That makes sense - but in the rest of the world, there may ALSO be a reason why the public can see the information, and don't have to get the owner's permission to see it (for example, who owns the house next door to yours if the house is sliding down the hill and you need to ready the home owner.) If could be reasonable to have a rule set for domains that allows the domain owner to approve release of ownership/contact information on a case by case basis, but it's likely a system like that will be ignored by most domain owners and they will not respond to a valid and beneficial request for access to the information (e.g., to allow a CA to issue a cert at the domain owner's request) Quite how we express that in terms of policy that appropriately translates to the GDPR etc is something we do not quite understand. Does the GDPR allow exceptions to privacy when reasonably necessary for the provision of goods and services to the data owner? It sounds as if you agree with the drafting teams point that data for other certification purposes, eg EV certificates, needs to be sourced outside the RDS/ WHOIS system in any case, and so is largely not relevant to working group discussion? On the provision of EV certificates, most of the identity information comes from third party data sources (state and national corporate registry agencies (Secretary of State's records, Companies House UK), private corporate data sources like Hoover's/Dun & Bradstreet, etc.) However, EV certificates also require confirmation of domain ownership or control for domains to be included in the certificate, which defaults back to the 10 methods for domain validation - which also includes access to WhoIs data for some of the validation methods. If these methods become unavailable because WhoIs-type data becomes unavailable, it will be much harder for many website owners to confirm their domains and obtain certificates to encrypt their websites - the other domain confirmation methods require active demonstrations of control of the domain like posting a unique Random Value supplied by the CA at a specific place on each of their websites, or in each of their DNS records for each domain. This will not be popular! The various methods involving web or dns entries are notable in that they provide an alternative, but I think there is a general understanding that many people will prefer to use the BR 3.2.2.4.x methods, and this should remain possible for those that wish it. Quite what that means at each stage of the policy process is not always clear. Yes, that is correct. Proving control of a domain by making an agreed upon change to the website is Method 6 (BR 3.2.2.4.6), and by making a change to the DNS record is Method 7 (BR 3.2.2.4.7). But other methods, like Methods 1, 2, and 3 require access to WhoIs records, and is generally easier for the domain owner to complete. In some companies, the person who buys a certificate for the website is not the same person who controls the webpages or who controls the DNS records, and it can be hard to coordinate within the company if Methods 6 or 7 are used. I understand there are policy and legal reasons why Registrars/Registries may not want to display WhoIs data to the public - but would it be possible for each Registrar/Registry to "whitelist" all the commercial CAs so that they may have access to the data? Some system should be possible, but the general question of how we validate/ certify access has not been addressed, and we don't plan to get into that for a while. Hopefully some fruitful discussions will take place at the face to face meeting - will you be there, Kirk? I would recommend that a standard form of access agreement (giving CAs access to WhoIs data of Registrars and Registries) be created, to be used on an optional basis by registrars and registries to set the terms and conditions for access to the data. This could include terms prohibiting the CA from mining the data and reselling it, etc. It might even be possible for the CA/Browser Forum to adopt "Standard Terms and Conditions for access to WhoIs Data by Certification Authorizes" in the Forum's Baseline Requirements document (non-mandatory), in consultation with ICANN, so that participating registrars and registries can simply make a statement "We are hereby giving access to our WhoIs data to the Certification Authorities listed here (ccadb.org list) subject to the Standard Terms and Conditions found here (link to standard document in CA/Browser Forum Baseline Requirements) - in that way, the registrars/registries would not have to come up with their own legal terms, and would not have to sign an agreement one-by-one with each CA in the world. If ICANN is interested in that approach for access to WhoIs data, the Forum can work on it. I personally think the CAs getting the information will be a relatively easy case - clearly the applicants have assented, the list of authorized CAs should be fairly uncontroversial, and if it is only the information required above that is needed, then it is a well defined list. This is much less controversial than some other data access issues we will need to address. But as I said, we aren't quite at that point yet. Let me know if you have any questions which commercial CAs can answer. I will be leading a face-to-face meeting of the CA/Browser Forum this Wednesday-Thursday in Washington, so it would be a good time to pull in the CAs and browsers on these issues. Great. I think our main question at this point is essentially if any uses of WHOIS data outside the voluntary use of data for establishing domain control is needed. Just one slight point here - in most cases we use WhoIs data to prove control, but for certificates that contain identity data also, we use the WhoIs data to link the proof of domain control to a proven identity - so we prove Foo Corporation exists at a location, and then we prove foo.com is owned by Foo Corporation before putting it in the OV or EV certificate. David Best regards. Kirk Hall Entrust Datacard Chair, CA/Browser Forum From: Gnso-rds-pdp-3 [mailto:gnso-rds-pdp-3-bounces@icann.org] On Behalf Of Terri Agnew Sent: Monday, March 5, 2018 3:34 PM To: gnso-rds-pdp-3@icann.org<mailto:gnso-rds-pdp-3@icann.org> Cc: gnso-secs@icann.org<mailto:gnso-secs@icann.org> Subject: [EXTERNAL][Gnso-rds-pdp-3] added Kirk Hall/ RDS drafting team 3 / Reconvening Domain Name Certification team 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: terri.agnew@icann.org<mailto:terri.agnew@icann.org> Skype ID: terri.agnew.icann Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_gn...> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGNSO&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=r-Nirn4kOYGkwbVx0VsP9wXIoGGzhrrchbSexWZfRoA&m=QDLdE7GSRvT2PTOhOMzt1I0noe5XUB5ngFGMmfm3lPA&s=02D65xo3ZOtO04quRILzuxfhKuEQQYPcR7SuU-_ok6I&e=> Follow the GNSO on Facebook: https://www.facebook.com/icanngnso/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_icanngnso_&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=r-Nirn4kOYGkwbVx0VsP9wXIoGGzhrrchbSexWZfRoA&m=QDLdE7GSRvT2PTOhOMzt1I0noe5XUB5ngFGMmfm3lPA&s=8yO1ZAfI1tFbgEHDfdOg9G1B2SJv7XputxVTnr-4kLo&e=> http://gnso.icann.org/en/<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=r-Nirn4kOYGkwbVx0VsP9wXIoGGzhrrchbSexWZfRoA&m=QDLdE7GSRvT2PTOhOMzt1I0noe5XUB5ngFGMmfm3lPA&s=GIXM-hU-TQOBHH0He_j2DfjT6L32vu5UTZcscRXO4CY&e=> _______________________________________________ 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://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Drds-2Dpdp-2D3&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=r-Nirn4kOYGkwbVx0VsP9wXIoGGzhrrchbSexWZfRoA&m=QDLdE7GSRvT2PTOhOMzt1I0noe5XUB5ngFGMmfm3lPA&s=7M6r9txJNgWZ7AQPV71SEZktvsiYEZDP2twT89rXsQY&e=>
Responses to your inline comments. I will chop some discussion out for clarity.
On 7 Mar 2018, at 1:02 am, Kirk Hall <Kirk.Hall@entrustdatacard.com> wrote:
David, I’m new to this discussion, and don’t have all the context of the prior discussion. Also, I may not use the right terminology.
Yes, and this working group (and ICANN in general) tends to grind very fine, with a lot of focus on specific details. All of your comments are useful, but some are not applicable to the precise task we are dealign with right now. This shouldn’t discourage you from commenting, just don’t get surprised when you have to make the same arguments later in a different context. Possibly a LOT later on some issues (we are not yet addressing specific implementation issues, that comes later in ‘Phase 2'). David
That is close to our understanding, that WHOIS data is one of the methods used to demonstrate domain control. Disputes in the working group have centered around issues of data exactly what constitutes legitimate data collection, and its implications. As CAs, we have no position on what data collection is “legitimate” – but we view the WhoIs record is like an auto registry system or real estate registry system – it is intended to show (1) ownership (with enough information to disambiguate if there ar 5 “David Cakes” in your city – so address and phone number help here, (2) means of contacting the owner for a valid purpose (e.g., a complaint if the registered car was part of an auto accident, an offer to buy the registered house from the owner, or a lawsuit against the registered domain owner if libelous information was posted on the site). In other parts of society, the gathering of ownership and contact information is generally viewed as legitimate as part of everyday commerce. For a domain owner, listing ownership and contact information in the WhoIs record is a normal part of doing other transactions that are beneficial to the domain owner, such as ordering a digital certificate to encrypt your website.
The discussion of ownership, and the requirement to demonstrate it, is very helpful and very germane to our current question. I added the point about disambiguation into the discussion of 3.2.2.4.1 The means of contacting the owner for a valid purpose is very applicable to this stage of the working groups work, but NOT to this drafting team, which is very specifically about Domain Name Certification as a purpose. Which does not mean that those other purposes are not applicable to the work of CAs - obviously, CAs might have their own business disputes with their customers, or may wish to contact another domain name that is involved in their business about a technical problem. But those other purposes are being discussed in detail in other drafting teams.
but in the rest of the world, there may ALSO be a reason why the public can see the information, and don’t have to get the owner’s permission to see it (for example, who owns the house next door to yours if the house is sliding down the hill and you need to ready the home owner.) If could be reasonable to have a rule set for domains that allows the domain owner to approve release of ownership/contact information on a case by case basis, but it’s likely a system like that will be ignored by most domain owners and they will not respond to a valid and beneficial request for access to the information (e.g., to allow a CA to issue a cert at the domain owner’s request)
Quite true, though again largely outside this Drafting Teams scope. It may also be that those that wish more granular control over their data, as you describe, may have to use a proxy or privacy service (a service many registrars offer for a small additional fee, though there are also independent providers).
Does the GDPR allow exceptions to privacy when reasonably necessary for the provision of goods and services to the data owner?
The short answer is yes, but the long answer seems to involve paying lawyers for some very long documents. Some legal analyses of the details are available in the group wiki or elsewhere on the ICANN web site. This working group commissioned some legal responses, ICANN in general has also acquired separate legal responses from a different firm, and there are other documents (including response from the Data Protection Agencies that administer the GDPR) as well. A significant issue is whether or not the customer has specifically consented.
On the provision of EV certificates, most of the identity information comes from third party data sources (state and national corporate registry agencies (Secretary of State’s records, Companies House UK), private corporate data sources like Hoover’s/Dun & Bradstreet, etc.) However, EV certificates also require confirmation of domain ownership or control for domains to be included in the certificate, which defaults back to the 10 methods for domain validation – which also includes access to WhoIs data for some of the validation methods.
That is pretty much as we thought. The EV certificates still require one of the Baseline Methods for demonstrating control, but that is the only use of
Proving control of a domain by making an agreed upon change to the website is Method 6 (BR 3.2.2.4.6), and by making a change to the DNS record is Method 7 (BR 3.2.2.4.7). But other methods, like Methods 1, 2, and 3 require access to WhoIs records, and is generally easier for the domain owner to complete. In some companies, the person who buys a certificate for the website is not the same person who controls the webpages or who controls the DNS records, and it can be hard to coordinate within the company if Methods 6 or 7 are used.
Yes. I’ve worked for web site clients and I’m well aware of the issues and alternatives here. The issues are largely around consent and defaults - I do not think anyone wants methods 1,2 and 3 to become impossible for those that opt-in to use them.
I would recommend that a standard form of access agreement (giving CAs access to WhoIs data of Registrars and Registries) be created, to be used on an optional basis by registrars and registries to set the terms and conditions for access to the data. This could include terms prohibiting the CA from mining the data and reselling it, etc. It might even be possible for the CA/Browser Forum to adopt “Standard Terms and Conditions for access to WhoIs Data by Certification Authorizes” in the Forum’s Baseline Requirements document (non-mandatory), in consultation with ICANN, so that participating registrars and registries can simply make a statement “We are hereby giving access to our WhoIs data to the Certification Authorities listed here (ccadb.org <http://ccadb.org/> list) subject to the Standard Terms and Conditions found here (link to standard document in CA/Browser Forum Baseline Requirements) – in that way, the registrars/registries would not have to come up with their own legal terms, and would not have to sign an agreement one-by-one with each CA in the world. If ICANN is interested in that approach for access to WhoIs data, the Forum can work on it.
That certainly sounds like a reasonable starting point, though there are many details to be worked out. But the working group also has to address some more complex issues (such as access by law enforcement, or access by those who make a living by resolving abuse issues on behalf of clients) and I suspect that we may end up with a more complex and nuanced access system in place. But again, that is very much outside the scope of this Drafting Team, and also quite a long way from where the working group is in its current discussion, which is very much focussed on purpose for data collection and access.
Just one slight point here – in most cases we use WhoIs data to prove control, but for certificates that contain identity data also, we use the WhoIs data to link the proof of domain control to a proven identity – so we prove Foo Corporation exists at a location, and then we prove foo.com <http://foo.com/> is owned by Foo Corporation before putting it in the OV or EV certificate.
Is this just proof of domain control in the sense of 3.2.2.4, or is there something else here? I do know there are a couple of points that maybe deserve a slightly closer look, like county information, but the current questions are just about identity. David
First, apologies for not responding to messages earlier – last week was the CA/Browser Forum meeting and too much travel. Responses inline. From: David Cake [mailto:dave@davecake.net] Sent: Monday, March 5, 2018 8:35 PM To: Kirk Hall <Kirk.Hall@entrustdatacard.com> Cc: gnso-rds-pdp-3@icann.org Subject: [EXTERNAL]Re: [Gnso-rds-pdp-3] added Kirk Hall/ RDS drafting team 3 / Reconvening Domain Name Certification team Welcome Kirk to the drafting team, and the working group. Your expertise is very welcome. On 6 Mar 2018, at 8:52 am, Kirk Hall <Kirk.Hall@entrustdatacard.com<mailto:Kirk.Hall@entrustdatacard.com>> wrote: Hi, drafting team – I’m Kirk Hall, and I work on policy and compliance issues with Certification Authority Entrust Datacard (plus I’m a recovering lawyer). Before that I was with the CA GeoTrust (acquired by Symantec) and later started the CA AffirmTrust (acquired by Entrust Datacard). I’m currently serving as Chair of the CA/Browser Forum. Marika Konings shared the drafting team memo “Domain Name Certification,” and it’s very good. I would just point out the WhoIs data is widely used by CAs for three different methods of domain confirmation – BR 3.2.2.4.1, .2, and .3 – and CAs and their website owner customers very much want the WhoIs information to continue to be available, as these three methods can be among the “easiest” for website owners, particularly enterprise owners with hundreds of domains. That is close to our understanding, that WHOIS data is one of the methods used to demonstrate domain control. Disputes in the working group have centered around issues of data exactly what constitutes legitimate data collection, and its implications. I think there is general agreement that if the data is collected for some purpose (and while it is possible that some changes may take place, it seems likely that data of at least rough equivalence will be collected), it should be possible for it to be voluntarily used for Domain Certification by those that wish it. Quite how we express that in terms of policy that appropriately translates to the GDPR etc is something we do not quite understand. It sounds as if you agree with the drafting teams point that data for other certification purposes, eg EV certificates, needs to be sourced outside the RDS/ WHOIS system in any case, and so is largely not relevant to working group discussion? [KH] Complicated issue. First, use of WhoIs Registrant information (Method 1) for domain validation was eliminated in a recent ballot because some thought the method was not secure enough (we disagreed). But there is discussion about bringing it back in a modified form. Second, Method 1 was used for both OV and EV certs. It presents a great advantage for enterprises with hundreds of domains – if they are properly registered to the organization in WhoIs, and the CA has done the identity and contact steps for the organization under BR 3.2.1 and 3.2.5, then the CA can issue (OV, EV, and even DV) certs for the customer simply by checking the Registrant in the WhoIs record. The domain owner is not required to do a “practical control” test for the domain (pasting a Random Value received from the CA on a specified web page for the domain or in the DNS record, etc.), which many enterprises with servers around the world can find hard to do. So in short, the WhoIs Registrant information was very useful to domain owners and CAs for all types of certs. If these methods become unavailable because WhoIs-type data becomes unavailable, it will be much harder for many website owners to confirm their domains and obtain certificates to encrypt their websites – the other domain confirmation methods require active demonstrations of control of the domain like posting a unique Random Value supplied by the CA at a specific place on each of their websites, or in each of their DNS records for each domain. This will not be popular! The various methods involving web or dns entries are notable in that they provide an alternative, but I think there is a general understanding that many people will prefer to use the BR 3.2.2.4.x methods, and this should remain possible for those that wish it. Quite what that means at each stage of the policy process is not always clear. [KH] WhoIs Registrant data is very useful for Methods 1 and 5 of BR 3.2.2.4.x, but as noted above have been (temporarily?) removed by a ballot of the Forum while modifications are being considered. We do need WhoIs data for other methods that involve emailing the contact email addresses or using the telephone number of the Registrant in the WhoIs record for a domain. I understand there are policy and legal reasons why Registrars/Registries may not want to display WhoIs data to the public – but would it be possible for each Registrar/Registry to “whitelist” all the commercial CAs so that they may have access to the data? Some system should be possible, but the general question of how we validate/ certify access has not been addressed, and we don’t plan to get into that for a while. Hopefully some fruitful discussions will take place at the face to face meeting - will you be there, Kirk? I personally think the CAs getting the information will be a relatively easy case - clearly the applicants have assented, the list of authorized CAs should be fairly uncontroversial, and if it is only the information required above that is needed, then it is a well defined list. This is much less controversial than some other data access issues we will need to address. But as I said, we aren’t quite at that point yet. [KH] This was not discussed at the F2F meeting of the Forum last week, but I think all CAs are hoping/assuming they will have continued access to the data in some way in the future. I think there’s a general feeling of, “Well, what is the data for if not to allow third parties a method for figuring out who owns the domain and how to contact them?” I think also that CAs generally feel that the current system, which allows a domain owner to opt out of public registration and use private registration, is sufficient to deal with privacy concerns. Let me know if you have any questions which commercial CAs can answer. I will be leading a face-to-face meeting of the CA/Browser Forum this Wednesday-Thursday in Washington, so it would be a good time to pull in the CAs and browsers on these issues. Great. I think our main question at this point is essentially if any uses of WHOIS data outside the voluntary use of data for establishing domain control is needed. [KH] I think you have captured the main issues, but CAs would prefer not to add an extra step of requiring customers to specifically open or authorize viewing of WhoIs data on a domain-by-domain basis to allow the CA to validate the domains – in many cases, tens or hundreds of domains come up for re-validation at the same time, and it seems that extra steps to open the WhoIs data each time might be more than the CA and domain owner can do. That would likely push them to some of the other methods that don’t use WhoIs data, but some of these methods have their own problems and/or vulnerabilities. (Methods 9 and 10 are limited in their permitted use right now because of security issues.) Also, there is one implementation of Method 1 that was preserved by the Forum – where the CA is both the customer’s Registrar/Registry and also its CA. The CA can just look at its own registrar records to confirm the customer owns the domain, then issue the certificate. I’m wondering if this implementation is consistent with the idea that all registrar/registry WhoIs data should be private? David Best regards. Kirk Hall Entrust Datacard Chair, CA/Browser Forum From: Gnso-rds-pdp-3 [mailto:gnso-rds-pdp-3-bounces@icann.org] On Behalf Of Terri Agnew Sent: Monday, March 5, 2018 3:34 PM To: gnso-rds-pdp-3@icann.org<mailto:gnso-rds-pdp-3@icann.org> Cc: gnso-secs@icann.org<mailto:gnso-secs@icann.org> Subject: [EXTERNAL][Gnso-rds-pdp-3] added Kirk Hall/ RDS drafting team 3 / Reconvening Domain Name Certification team 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: terri.agnew@icann.org<mailto:terri.agnew@icann.org> Skype ID: terri.agnew.icann Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages<https://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-...> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO Follow the GNSO on Facebook: https://www.facebook.com/icanngnso/ http://gnso.icann.org/en/ _______________________________________________ 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
participants (4)
-
David Cake -
Feher, Kal -
Kirk Hall -
Terri Agnew