[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