Re: [Sks-devel] Implications of GDPR

[H Visage]

On Sun, 29 Apr 2018, 19:04 Ari Trachtenberg,  wrote:

>
> On Apr 29, 2018, at 12:20 PM, Moritz Wirth  wrote:
>
>
> The last thing is about data protection - I am pretty sure the data in the
> reconciliation process is not encrypted (which would be useless for public
> data) but may also be required for data exchanges by GDPR  - the same goes
> for retrieval over https (which is tbh not really supported)
>
>
> I don’t remember whether sks uses a single-stage or two-stage process for
> reconciliation … in a single-stage
> process, data is directly encoded as evaluations of a rational function,
> so only another peer with similar
> data will be able to decode it.
>
> In a two-stage process, the initial phase is done on hashes, and a second
> stage transfers the data corresponding
> to differing hashes.  It should be possible for the second stage can be
> sent over an encrypted tunnel without
> too much effort.
>

And then the data is requested over HTTP unencrypted by the pgp-client or
web interface


> best,
> -Ari
>
>
> Sent from my iPhone
>
> Am 29.04.2018 um 17:08 schrieb robots.txt fan  >:
>
> Moritz Wirth wrote:
>
> Given the fact that it is not possible to delete data from a keyserver
>
>
> Of course this is possible. You can delete key by using the "sks drop
> " command. Now, if I understand it correctly the key will immediately
> be re-added because of gossiping keyservers. However, it would not be
> impossible to extend SKS to have a keyserver reject keys from a blacklist
> that each server admin would maintain, or possibly gossip. (If this does
> not exist already.)
>
> I imagine this would be a useful instrument for more use-cases than this
> one. I imagine a server admin based in Germany would get in trouble if
> someone submitted a key with the user-id "The owner of this server denies
> the Holocaust", an action that is illegal in Germany.  The server admin
> could get out of the trouble by adding the hash of that key to the
> blacklist.
>
> I know I am suggesting censorship but it's not like SKS was ever meant to
> be a secure or reliable channel.
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
>
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
>
> ---
> Prof. Ari TrachtenbergECE, Boston University
> trach...@bu.eduhttp://people.bu.edu/trachten
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Implications of GDPR

[Ari Trachtenberg]

> On Apr 29, 2018, at 12:20 PM, Moritz Wirth  wrote:

> The last thing is about data protection - I am pretty sure the data in the 
> reconciliation process is not encrypted (which would be useless for public 
> data) but may also be required for data exchanges by GDPR  - the same goes 
> for retrieval over https (which is tbh not really supported)

I don’t remember whether sks uses a single-stage or two-stage process for 
reconciliation … in a single-stage
process, data is directly encoded as evaluations of a rational function, so 
only another peer with similar
data will be able to decode it.

In a two-stage process, the initial phase is done on hashes, and a second stage 
transfers the data corresponding
to differing hashes.  It should be possible for the second stage can be sent 
over an encrypted tunnel without
too much effort.

best,
-Ari

> 
> Sent from my iPhone
> 
>> Am 29.04.2018 um 17:08 schrieb robots.txt fan :
>> 
>> Moritz Wirth wrote:
>>> Given the fact that it is not possible to delete data from a keyserver
>> 
>> Of course this is possible. You can delete key by using the "sks drop 
>> " command. Now, if I understand it correctly the key will immediately 
>> be re-added because of gossiping keyservers. However, it would not be 
>> impossible to extend SKS to have a keyserver reject keys from a blacklist 
>> that each server admin would maintain, or possibly gossip. (If this does not 
>> exist already.)
>> 
>> I imagine this would be a useful instrument for more use-cases than this 
>> one. I imagine a server admin based in Germany would get in trouble if 
>> someone submitted a key with the user-id "The owner of this server denies 
>> the Holocaust", an action that is illegal in Germany.  The server admin 
>> could get out of the trouble by adding the hash of that key to the blacklist.
>> 
>> I know I am suggesting censorship but it's not like SKS was ever meant to be 
>> a secure or reliable channel.
>> 
>> ___
>> Sks-devel mailing list
>> Sks-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/sks-devel
> 
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel

---
Prof. Ari TrachtenbergECE, Boston University
trach...@bu.eduhttp://people.bu.edu/trachten



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Implications of GDPR

[Moritz Wirth]

That does not solve the problem with the data deletion - the key id can be 
tracked to a person and would be therefore considered as personal Information 
so you would be still required to delete the key id itself.

The other big problem is the data sharing over reconciliation and other methods 
- you need the agreement by the user and all peering partners to do this - so 
you have to tell the user that you store his data regardless if he uses the 
website ( which would be easy) or the pgp client and it might be possible that 
you need the possibility to opt out of the reconprocess

The last thing is about data protection - I am pretty sure the data in the 
reconciliation process is not encrypted (which would be useless for public 
data) but may also be required for data exchanges by GDPR  - the same goes for 
retrieval over https (which is tbh not really supported) 

Sent from my iPhone

> Am 29.04.2018 um 17:08 schrieb robots.txt fan :
> 
> Moritz Wirth wrote:
>> Given the fact that it is not possible to delete data from a keyserver
> 
> Of course this is possible. You can delete key by using the "sks drop " 
> command. Now, if I understand it correctly the key will immediately be 
> re-added because of gossiping keyservers. However, it would not be impossible 
> to extend SKS to have a keyserver reject keys from a blacklist that each 
> server admin would maintain, or possibly gossip. (If this does not exist 
> already.)
> 
> I imagine this would be a useful instrument for more use-cases than this one. 
> I imagine a server admin based in Germany would get in trouble if someone 
> submitted a key with the user-id "The owner of this server denies the 
> Holocaust", an action that is illegal in Germany.  The server admin could get 
> out of the trouble by adding the hash of that key to the blacklist.
> 
> I know I am suggesting censorship but it's not like SKS was ever meant to be 
> a secure or reliable channel.
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel


___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Implications of GDPR

[robots.txt fan]

Moritz Wirth wrote:
> Given the fact that it is not possible to delete data from a keyserver

Of course this is possible. You can delete key by using the "sks drop " 
command. Now, if I understand it correctly the key will immediately be re-added 
because of gossiping keyservers. However, it would not be impossible to extend 
SKS to have a keyserver reject keys from a blacklist that each server admin 
would maintain, or possibly gossip. (If this does not exist already.)

I imagine this would be a useful instrument for more use-cases than this one. I 
imagine a server admin based in Germany would get in trouble if someone 
submitted a key with the user-id "The owner of this server denies the 
Holocaust", an action that is illegal in Germany.  The server admin could get 
out of the trouble by adding the hash of that key to the blacklist.

I know I am suggesting censorship but it's not like SKS was ever meant to be a 
secure or reliable channel.

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Implications of GDPR

[Klaus-Uwe Mitterer]

Hi Moritz,

My understanding is that the section you quoted on the "right to be
forgotten" refers to the controller's (i.e. your) obligation to inform
_other_ controllers processing the data (in this case: other keyserver
operators who, through gossip, have a "copy or replication" of the
personal data) about the data subject's request for deletion. "Technical
measures" in this context would, for instance, be a way to automatically
propagate the deletion to other servers; as this is not possible, you
only have to take "reasonable steps" to inform others, like sending an
email to your peers. If somebody wants you to delete their data, you
will definitely have to delete it, regardless of how difficult this is
to achieve with SKS.

A whole different issue is how you would get a data subject's permission
to process their data in the first place, and how you would notify them
about the fact that you are processing their data, both of which are
required by the GDPR.

Regards

Klaus-Uwe


On 2018-04-29 13:02, Moritz Wirth wrote:
> Hi Fabian,
>
> first of all, I am not a lawyer so you should not rely on my response as
> it may be wrong :)
>
> - The GDPR applies to all persons and companies who are located in the
> EU or offering goods, services or who monitor the behavior of EU data
> subjects - this means that all keyservers are affected regardless where
> they are physically located. (https://www.eugdpr.org/gdpr-faqs.html)
>
> - Personal Data includes Names, Photos, social posts, IP-Addresses.. (so
> it seems that everything that can be connected to a person is included
> here).
>
> - The Right to be forgotten: People have the right to get their data
> deleted if it is no longer necessary in relation to the purpose they
> were collected. I think this means that if someone wants to have their
> data deleted, you have to delete it - given the fact above that some
> keys include personal name or even photos, you would be required to
> delete them (even if you are in the USA). However, I am not sure - the
> text says "the controller, taking account of available technology and
> the cost of implementation, shall take reasonable steps, including
> technical measures, to inform controllers which are processing the
> personal data that the data subject has requested the erasure by such
> controllers of any links to, or copy or replication of, those personal
> data." <-- Given the fact that it is not possible to delete data from a
> keyserver, I am not sure how this would be handled. (Same applies to for
> reasons of public interest in the area of public health in accordance
> with points (h) and (i) of Article 9(2) as well as Article 9(3) but I
> didnt check on that). (https://gdpr-info.eu/art-17-gdpr/)
>
> - I heard that you must sign (physical) contracts with data processing
> companies (this may also include Google and Google Analytics, I am not
> sure about Google Fonts etc but since Google gets your IP...) if you
> share the data of your user with them (e.g using GA on your site).
> ("Controller will need to have in place an appropriate contract with any
> other Controller that it jointly shares data with if that Controller
> particularly is outside the EU."). Should not really matter (except for
> Google Fonts) - at the end the use of Tracking services is up to the
> keyserver admin itself
> (https://www.netskope.com/blog/gdpr-data-processing-agreements/)
>
> The first thing I would do is to include a checkbox in the webtemplate
> that every person who queries or uploads a key via the webinterface
> agrees to your data policy - in the data policy you should explain what
> happens when a key is uploaded, that it is distributed to other
> keyservers, (IPs are collected whatever you do) and that it is not
> possible to delete keys once they are uploaded.
>
> If someone has more information on this or something to correct feel
> free to do so :)
>
> Best regards,
>
> Moritz
>
>
> Am 29.04.18 um 12:24 schrieb Fabian A. Santiago:
>> So,
>>
>> As I understand it, GDPR concerns all EU citizen users of a site, regardless 
>> of where the site is hosted. How does this affect keyservers? I've seen at 
>> least one server going offline due to it. Should I be concerned as an 
>> American keyserver host? 
>> --
>>
>> Fabian A. Santiago
>>
>> OpenPGP:
>>
>> 0x643082042dc83e6d94b86c405e3daa18a1c22d8f (current key)
>>  0x3c3fa072accb7ac5db0f723455502b0eeb9070fc (to be retired / revoked)
>>
>> ___
>> Sks-devel mailing list
>> Sks-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
>
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel

-- 
Klaus-Uwe Mitterer

Email: email@kumi.email  

XMPP: kumitte...@kumi.zone  
Twitter: @kumitterer  
Threema: PEBXP4H3
Telegram: @kumitterer

Skype: kumitterer  
Mobile: +43 660 6340166  

*** DISCLAIMER ***
This document is only 

Re: [Sks-devel] Implications of GDPR

[chris]

My short response to all of that is: "meh".

Less briefly: Technically, I think you're right.  The whole keyserver system 
doesn't appear to work at all against GDPR.  But equally, a _system_ like ours 
doesn't seem a very likely target of any regulators.  The law was mostly 
envisioned to keep *companies* in line - not a disparate collection of 
individuals running a service as a hobby.   After all, most European countries 
already had existing individual privacy laws that the keyservers were 
theoretically already in breach of.  

I'll personally risk it - but as you note - I'm not a lawyer either.  

Regards,
Chris


-Original Message-
From: Sks-devel [mailto:sks-devel-bounces+chris=funderburg...@nongnu.org] On 
Behalf Of Moritz Wirth
Sent: 29 April 2018 12:03
To: Fabian A. Santiago ; sks-devel 

Subject: Re: [Sks-devel] Implications of GDPR

Hi Fabian,

first of all, I am not a lawyer so you should not rely on my response as it may 
be wrong :)

- The GDPR applies to all persons and companies who are located in the EU or 
offering goods, services or who monitor the behavior of EU data subjects - this 
means that all keyservers are affected regardless where they are physically 
located. (https://www.eugdpr.org/gdpr-faqs.html)

- Personal Data includes Names, Photos, social posts, IP-Addresses.. (so it 
seems that everything that can be connected to a person is included here).

- The Right to be forgotten: People have the right to get their data deleted if 
it is no longer necessary in relation to the purpose they were collected. I 
think this means that if someone wants to have their data deleted, you have to 
delete it - given the fact above that some keys include personal name or even 
photos, you would be required to delete them (even if you are in the USA). 
However, I am not sure - the text says "the controller, taking account of 
available technology and the cost of implementation, shall take reasonable 
steps, including technical measures, to inform controllers which are processing 
the personal data that the data subject has requested the erasure by such 
controllers of any links to, or copy or replication of, those personal data." 
<-- Given the fact that it is not possible to delete data from a keyserver, I 
am not sure how this would be handled. (Same applies to for reasons of public 
interest in the area of public health in accordance with points (h) and (i) of 
Article 9(2) as well as Article 9(3) but I didnt check on that). 
(https://gdpr-info.eu/art-17-gdpr/)

- I heard that you must sign (physical) contracts with data processing 
companies (this may also include Google and Google Analytics, I am not sure 
about Google Fonts etc but since Google gets your IP...) if you share the data 
of your user with them (e.g using GA on your site).
("Controller will need to have in place an appropriate contract with any other 
Controller that it jointly shares data with if that Controller particularly is 
outside the EU."). Should not really matter (except for Google Fonts) - at the 
end the use of Tracking services is up to the keyserver admin itself
(https://www.netskope.com/blog/gdpr-data-processing-agreements/)

The first thing I would do is to include a checkbox in the webtemplate that 
every person who queries or uploads a key via the webinterface agrees to your 
data policy - in the data policy you should explain what happens when a key is 
uploaded, that it is distributed to other keyservers, (IPs are collected 
whatever you do) and that it is not possible to delete keys once they are 
uploaded.

If someone has more information on this or something to correct feel free to do 
so :)

Best regards,

Moritz


Am 29.04.18 um 12:24 schrieb Fabian A. Santiago:
> So,
>
> As I understand it, GDPR concerns all EU citizen users of a site, regardless 
> of where the site is hosted. How does this affect keyservers? I've seen at 
> least one server going offline due to it. Should I be concerned as an 
> American keyserver host? 
> --
>
> Fabian A. Santiago
>
> OpenPGP:
>
> 0x643082042dc83e6d94b86c405e3daa18a1c22d8f (current key)  
> 0x3c3fa072accb7ac5db0f723455502b0eeb9070fc (to be retired / revoked)
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel




___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Implications of GDPR

[Moritz Wirth]

Hi Fabian,

first of all, I am not a lawyer so you should not rely on my response as
it may be wrong :)

- The GDPR applies to all persons and companies who are located in the
EU or offering goods, services or who monitor the behavior of EU data
subjects - this means that all keyservers are affected regardless where
they are physically located. (https://www.eugdpr.org/gdpr-faqs.html)

- Personal Data includes Names, Photos, social posts, IP-Addresses.. (so
it seems that everything that can be connected to a person is included
here).

- The Right to be forgotten: People have the right to get their data
deleted if it is no longer necessary in relation to the purpose they
were collected. I think this means that if someone wants to have their
data deleted, you have to delete it - given the fact above that some
keys include personal name or even photos, you would be required to
delete them (even if you are in the USA). However, I am not sure - the
text says "the controller, taking account of available technology and
the cost of implementation, shall take reasonable steps, including
technical measures, to inform controllers which are processing the
personal data that the data subject has requested the erasure by such
controllers of any links to, or copy or replication of, those personal
data." <-- Given the fact that it is not possible to delete data from a
keyserver, I am not sure how this would be handled. (Same applies to for
reasons of public interest in the area of public health in accordance
with points (h) and (i) of Article 9(2) as well as Article 9(3) but I
didnt check on that). (https://gdpr-info.eu/art-17-gdpr/)

- I heard that you must sign (physical) contracts with data processing
companies (this may also include Google and Google Analytics, I am not
sure about Google Fonts etc but since Google gets your IP...) if you
share the data of your user with them (e.g using GA on your site).
("Controller will need to have in place an appropriate contract with any
other Controller that it jointly shares data with if that Controller
particularly is outside the EU."). Should not really matter (except for
Google Fonts) - at the end the use of Tracking services is up to the
keyserver admin itself
(https://www.netskope.com/blog/gdpr-data-processing-agreements/)

The first thing I would do is to include a checkbox in the webtemplate
that every person who queries or uploads a key via the webinterface
agrees to your data policy - in the data policy you should explain what
happens when a key is uploaded, that it is distributed to other
keyservers, (IPs are collected whatever you do) and that it is not
possible to delete keys once they are uploaded.

If someone has more information on this or something to correct feel
free to do so :)

Best regards,

Moritz


Am 29.04.18 um 12:24 schrieb Fabian A. Santiago:
> So,
>
> As I understand it, GDPR concerns all EU citizen users of a site, regardless 
> of where the site is hosted. How does this affect keyservers? I've seen at 
> least one server going offline due to it. Should I be concerned as an 
> American keyserver host? 
> --
>
> Fabian A. Santiago
>
> OpenPGP:
>
> 0x643082042dc83e6d94b86c405e3daa18a1c22d8f (current key)
>  0x3c3fa072accb7ac5db0f723455502b0eeb9070fc (to be retired / revoked)
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel




signature.asc
Description: OpenPGP digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] Implications of GDPR

[Fabian A. Santiago]

So,

As I understand it, GDPR concerns all EU citizen users of a site, regardless of 
where the site is hosted. How does this affect keyservers? I've seen at least 
one server going offline due to it. Should I be concerned as an American 
keyserver host? 
--

Fabian A. Santiago

OpenPGP:

0x643082042dc83e6d94b86c405e3daa18a1c22d8f (current key)
 0x3c3fa072accb7ac5db0f723455502b0eeb9070fc (to be retired / revoked)

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel