[gnso-rds-pdp-wg] ICANN Blog re Session with European DPAs

Chuck consult at cgomes.com
Sat Mar 31 15:14:26 UTC 2018


Jonathan & Rubens,

 

In my message to the WG on 23 March, in light of the Community work on GDPR compliance work that is happening and fact that ICANN Org was seeking direction from European DPAs, I concluded by saying that the objectives of taking a break in our WG meetings was “to better understand impacts and make sure the work we do going forward makes sense in the larger picture and is respectful of the time commitments made by members of the working group”.  To be more precise, the two objectives are: 1) to allow us time to better understand the impacts on the RDS PDP WG so that we can maximize the effectiveness of WG activity; and 2) to respect the time of those in the WG who are extremely busy with the GDRP work.  I believe that those objectives apply not only to taking a break in WG meetings but also to our WG list discussions.

 

While there is a break in the WG meetings and WG list discussions have been at a minimum level, the members of the WG leadership team have been very busy.  We held two conference calls this past week and spent many hours working online, exchanging email and Skype messages with one another and with the GNSO Council leaders.  I fully expect that activity to continue for at least the next two weeks and possibly longer.  

 

Regarding objective 1, we do not yet know the impacts of the GDPR work on the RDS PDP WG.  To facilitate that I sent a message developed by the leadership team to the Council leaders yesterday specifically requesting that they seek some clarification from the ICANN Board.   We hope to get that clarification in the next week or two.  Regarding objective 2, many WG members are still spending excessive amounts of time on the GDPR work.  For these reasons, I do not think that this is the best time to initiate a new discussion.

 

As I have said before, the GDPR work that is happening has a lot of relevance to what the WG is doing, so I suspect that the WG will eventually need to have discussions on topics like both of you suggest.  As you are probably aware, email has been a key topic of GDRP discussions.  It seems likely that specific decisions about email will be made as part of any interim GDPR model that is chosen.  I think that WG time will be better spent once we know how the interim model will deal with email.

 

Chuck

 

 

 

From: gnso-rds-pdp-wg <gnso-rds-pdp-wg-bounces at icann.org> On Behalf Of Rubens Kuhl
Sent: Friday, March 30, 2018 12:20 PM
To: jdm at riskiq.net
Cc: RDS PDP WG <gnso-rds-pdp-wg at icann.org>
Subject: Re: [gnso-rds-pdp-wg] ICANN Blog re Session with European DPAs

 

 





On 30 Mar 2018, at 13:08, jonathan m <jonathan.matkowsky at riskiq.net <mailto:jonathan.matkowsky at riskiq.net> > wrote:

 

Hi Chuck—I’d like to get a discussion going if that’s okay with you. I’d like to know whether for the public data set, it is feasible to have the following solution for the registrant email. It’s based in part on both technical implications and policy requirements. 

 

While the discussion sounds more like a GDPR discussion than an RDS discussion, there is always something that might be applicable to the PDP. For the GDPR part of this discussion, writing to the specific ICANN section sounds more productive. 

 





 

1) Registrar required to notify registrants that starting on x date, the registrant org field will be relied on for purposes of treating the Whois record as an organizational domain rather than as belonging to a natural person. Check your record for accuracy because it may have implications for your privacy if you do not already have or subscribe to proxy or privacy services. A few reminders go out. Educate registrants they may want to update to “Domain Admin” instead of having their first and last name for organizational domains because starting on x date, existing organizational records will otherwise obfuscate or mask the local part of the registrant email in public Whois

 

While a policy implementation can specify a transition period and triggers, the elevated number of gTLD registrations suggest that to be an Hercules work. Issues with this type of procedure include outdated e-mail addresses, fake messages pretending to be the real thing etc. 





 

2) For organizational domains, ICANN will prohibit masking the organizational domain name in the registrant email address. Registrars are free to mask the local part of the registrant email address in accordance with applicable law in the public Whois.

 

If that is done with a different syntax, they it could work. For instance, REMOVED at example.com <mailto:REMOVED at example.com>  would look a valid e-mail address, so that should be avoided. REMOVED at example.com <http://example.com>  would be better. 





 

3) for natural persons, registrars will be required to use the same encrypted hash algorith so there is parity across databases even though there is no centralized database to manage the encryption. The policy will be enforced by ICANN and subject to auditing. They can warn registrants of the associated risks of compromise to give them a chance to take added precautions and purchase proxy or privacy services.

 

This assumes that allowing others to correlate domains registered by the same e-mail address is not a violation of privacy rights. This is very debatable, and I've seen both angles being advocated for. 

 

On the cryptography part, I believe that this unsalted encrypted hash applied to such a large number of objects will be too weak, requiring constant updating. Some type of asymmetric encryption would likely be more appropriate for the task, although expanding the response size quite a bit. 





 

This would be the minimum requirements for modifying public Whois registrant email address to avoid damaging the security and stability of the unique identifiers and DNS. 

 

This is yet another attempt to confuse security and stability of the identifier system with security of applications using this identifier system such as Web and e-mail. While ICANN and ICANN community needs to be aware of the security implications of RDS choices, they do not impact security and stability of the identifier system. There is a continued attempt to equate the two, but that doesn't hold. It doesn't mean ICANN gTLD policies can't try taking it into account; for instance, if a gTLD policy would bring poverty and hunger to the world, we should avoid doing so. But this is different from being tasked with eliminating poverty and hunger. 

 





If the downside of doing this is prohibitive, than ICANN should seek guidance in the April meeting on whether the public interest in not damaging security and stability outweighs the privacy interference of having email addresses remain in the phone books given its not a particularly strong personal indicator to begin with as privacy and proxy services are available to those that mind as long as they are notified.

 

This sounds more like a GDPR discussion than a PDP discussion, again. I believe the WG is fully capable already of discussing this topic, either thru the list or thru calls if this topic gets into the agenda.





 

This would result in emails in Whois of natural data subjects being uniformly hashed so that you can freely see which hash owns what, and Whois of organizations being freely listed with any local part of such organizational emails being masked if required by applible law.

 

See above.





 

I would like to hear a discussion on this from the group this week. Not on the legality of it under GDPR as the Article 29 working group can weigh in but first we need to discuss the architectural and policy issues.

 

I believe the GDPR exercise will be very instructive in providing legal basis to do things one way, or legal basis to not things another way. Still, there might be some gray areas not covered by such basis requiring further enlightenment on its legality in jurisdictions across the world. We might have to wait to see which is which. 

 

 

Rubens

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20180331/14ecc5c7/attachment.html>


More information about the gnso-rds-pdp-wg mailing list