sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] Implications of GDPR


From: Moritz Wirth
Subject: Re: [Sks-devel] Implications of GDPR
Date: Sun, 29 Apr 2018 18:20:13 +0200

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 <address@hidden>:
> 
> 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 <hash>" 
> 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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/sks-devel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]