[Gnso-rds-pdp-3] [EXTERNAL]Re: added Kirk Hall/ RDS drafting team 3 / Reconvening Domain Name Certification team

Thu Mar 8 21:10:26 UTC 2018

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 at icann.org<mailto:gnso-rds-pdp-3-bounces at icann.org>> on behalf of Kirk Hall <Kirk.Hall at entrustdatacard.com<mailto:Kirk.Hall at entrustdatacard.com>>
Date: Wednesday, 7 March 2018 at 04:02
To: David Cake <dave at davecake.net<mailto:dave at davecake.net>>
Cc: "gnso-rds-pdp-3 at icann.org<mailto:gnso-rds-pdp-3 at icann.org>" <gnso-rds-pdp-3 at icann.org<mailto:gnso-rds-pdp-3 at 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 at davecake.net]
Sent: Monday, March 5, 2018 11:35 PM
To: Kirk Hall <Kirk.Hall at entrustdatacard.com<mailto:Kirk.Hall at entrustdatacard.com>>
Cc: gnso-rds-pdp-3 at icann.org<mailto:gnso-rds-pdp-3 at 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 at entrustdatacard.com<mailto:Kirk.Hall at 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 at icann.org] On Behalf Of Terri Agnew
Sent: Monday, March 5, 2018 3:34 PM
To: gnso-rds-pdp-3 at icann.org<mailto:gnso-rds-pdp-3 at icann.org>
Cc: gnso-secs at icann.org<mailto:gnso-secs at 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 at icann.org<mailto:terri.agnew at 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_gnso.icann.org_files_gnso_presentations_policy-2Defforts.htm-23newcomers&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=r-Nirn4kOYGkwbVx0VsP9wXIoGGzhrrchbSexWZfRoA&m=QDLdE7GSRvT2PTOhOMzt1I0noe5XUB5ngFGMmfm3lPA&s=z1sNA97eNGaTr0sFMfkeXdy5EnDDiLDlVQlHay0E9Dg&e=>
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 at icann.org<mailto:Gnso-rds-pdp-3 at 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=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-3/attachments/20180308/6f9535e8/attachment-0001.html>