Re: [Sks-devel] Implications of GDPR
> On 4 May 2018, at 22:56, Arnoldwrote: > > If keyserver A has configured Set A and keyserver B has configured Set B, the > set > reconciliation algorithm between keyservers A and B should only consider Set > C, > where Set C is the intersection of sets A and B. The set reconciliation > algorithm > can be used the same The main difference between this proposal and the one that Phil, myself and others are discussing in the other thread is that here the servers need to agree on the definition of these sets in advance, and servers that do not understand the sets (perhaps because they are too old) will be unable to recon with those that serve a restricted set. The advantage of fake recon is that a) it can be deployed incrementally while maintaining recon between old and new software versions and b) there is no need for a commonly agreed definition of sets. A ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Implications of GDPR
On 04-05-18 10:44, dirk astrath wrote: > It may make sense to keep a revoked key in our database: > How is your decision, if a key can't be found on a keyserver? > Trust on first use? Don't trust? This should, IMO, all be a local, individual decision. I am currently looking into 'value sensitive design', making systems that are adjustable to specific human values in different human societies. [ https://vsdesign.org/ ] > If my key gets compromised, I want ... > Therefore: > If ..., I'm unable to ... In many messages in the current discussion, it is very easy to spot examples of a need for value sensitive design, like in these few lines above. > All in all: > > It's not easy to find a perfect solution (if there is any) ... and it's > not the first time we have this discussion ... In 2015, the idea came up to let go of the idea of a single set that gets synchronised. Instead of one single set, we can define parametrised filters to create 'value sensitive sets' ;-) [ http://lists.nongnu.org/archive/html/sks-devel/2015-05/msg00062.html ] If keyserver A has configured Set A and keyserver B has configured Set B, the set reconciliation algorithm between keyservers A and B should only consider Set C, where Set C is the intersection of sets A and B. The set reconciliation algorithm can be used the same. In case the operator of keyserver A finds that his Set A is "larger" than the union of all Sets of its peers, that operator can ask on this very mailing list for peering with keyservers that have the missing subset (based on the configured parameters of the filters). At least this might be a solution to the keyserver compatibility problem. For the pool, we might end up with sub-pools based on filter parameters. If operators don't do fancy filtering of their own, but follow local law, we might end up with regional pools, possibly based on groups of countries, with a maximum of the number of countries in the world ;-) Kind regards, Arnold ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Implications of GDPR
Hi, It may make sense to keep a revoked key in our database: How is your decision, if a key can't be found on a keyserver? Trust on first use? Don't trust? If my key gets compromised, I want to tell the community: DO NOT trust this key ... so I revoke it. Therefore: If revoked (or expired) keys are removed from keyservers, I'm unable to tell this anymore. Another issue are the "fake" keys or keys, which have been uploaded a long time ago. Even if you're the owner (or former owner) of the username/mailadress-combination you're unable to revoke the key or add any (trusted) signature to this key so it will get removed (or unlisted). So these key can't get removed from the database. Well ... using any fake email-adress i would be able to write "somebody" "please remove my key from keyserver", but ... how am I able to proof that I'm the one who is allowed to get this key removed? And ... even if I have to answer to a "ping"-mail: If the domain doesn't exist anymore (or belongs to somebody else) I will not be able to answer and therefore confirm the deletion. All in all: It's not easy to find a perfect solution (if there is any) ... and it's not the first time we have this discussion ... ... the first time I remember it was after the talk on OHM 2013 "Trolling the Openpgp-Web-of-trust" ... unfortunately nothing changed since then ... ;-( Kind regards, dirk signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Implications of GDPR
On 05/03/2018 07:40 AM, Moritz Wirth wrote: > That does not help because you still Store european data which is still > affected by the GDPR. > > What about only accepting valid keys and removing all revoked or expired > keys from the database? If someone wants to have his data deleted he can > revoke his key and the revoked signature is synced over all keyservers > which then delete them from their own db - new revoked keys are simply > rejected. > how do you determine the "validity" of a key? do you mean in the technical sense (not expired, revoked, etc.)? because others have pointed out the issue with that. or do you mean proving a user owns a key they push? if so, that has its own problems- sure, you could send an email to the email address associated with the key and require a reply (such as what keyserver.pgp.com did - does? haven't used in a while), BUT... not all keys have addresses associated (and this is the preferred method for addressing the - admittedly, in my opinion, unfounded but still commonplace - concern of spammers harvesting email addresses from keys). -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Implications of GDPR
On 2018-05-03 08:58, Andrew Gallagher wrote: On 03/05/18 12:40, Moritz Wirth wrote: What about only accepting valid keys and removing all revoked or expired keys from the database? I assume you mean "remove the user-id packets of all revoked or expired keys"? You would have to retain at least the revocation signature and the primary key, to make sure that nobody tried to re-upload a non-revoked copy of the key, and to make sure that the keyservers still served their primary purpose of distributing key revocations. But the primary key could itself be considered personal data... ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel i support the idea of local blacklists and being able to remove keys upon request. but sadly i'm not a developer so i can't contribute to such a cause. -- -- Thanks, Fabian S. OpenPGP: 0x3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC (to be revoked) 0x643082042DC83E6D94B86C405E3DAA18A1C22D8F (new key) 0xA1C22D8F.asc Description: application/pgp-keys ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Implications of GDPR
On 03/05/18 12:40, Moritz Wirth wrote: > What about only accepting valid keys and removing all revoked or expired > keys from the database? I assume you mean "remove the user-id packets of all revoked or expired keys"? You would have to retain at least the revocation signature and the primary key, to make sure that nobody tried to re-upload a non-revoked copy of the key, and to make sure that the keyservers still served their primary purpose of distributing key revocations. But the primary key could itself be considered personal data... -- Andrew Gallagher signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Implications of GDPR
> What about only accepting valid keys and removing all revoked or expired keys > from the database? If someone wants to have his data deleted he can revoke > his key and the revoked signature is synced over all keyservers which then > delete them from their own db - new revoked keys are simply rejected. > >> Actually anybody can send in your name and e-mail address (with a fake key > >> of course). You cannot revoke a key with your name and address placed by someone else. Gabor ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Implications of GDPR
That does not help because you still Store european data which is still affected by the GDPR. What about only accepting valid keys and removing all revoked or expired keys from the database? If someone wants to have his data deleted he can revoke his key and the revoked signature is synced over all keyservers which then delete them from their own db - new revoked keys are simply rejected. Sent from my iPad > On 3. May 2018, at 13:26, Ari Trachtenbergwrote: > > … or keep sks servers out of Europe. > >>> On May 3, 2018, at 3:35 AM, Gabor Kiss wrote: >>> >>> I'm thinking the problem is much simpler than its being made out to be. >>> For the data to have got in to the SKS system the user must push it >>> there. Its not like we are gathering the data in the background like FB >> >> Actually anybody can send in your name and e-mail address (with a fake key >> of course). >> >>> or Google, so its the users responsibility control the data and delete >>> it if needed. >> >> IMHO the current form of key servers won't survive the GDPR. >> We have to destroy it then to rebuild from scratch. >> >> My suggestion a key server should accept keys only with a special >> ID record: >> "This is a public information as written on http://gdpr.example.com; >> or so. That is signed by owner. Whose identity is verified by someone else. >> So key server is a toy for the strong set only. At least in the first >> few years. >> >> Gabor >> >> ___ >> 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
On 29/04/2018 7:54 PM, Fabian A. Santiago wrote: > 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 I'm thinking the problem is much simpler than its being made out to be. For the data to have got in to the SKS system the user must push it there. Its not like we are gathering the data in the background like FB or Google, so its the users responsibility control the data and delete it if needed. I do think the SKS system need a way of being told by a key owner that they want the data to be deleted, this then get propagated as an update. Once all the peers of an SKS Server know about a deletion request all the data (including the key could be deleted). There might be a problem with a re-add loop even with the above rule so maybe a local black list might be needed. Any how my 2 cents worth Mike ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Implications of GDPR
On 04/30/2018 01:59 PM, Andrew Gallagher wrote: > Certificate validation may also be an issue, because many HTTPS pool > members only have the pool SSL certificate - which won't validate in the > normal manner when bypassing the pool round-robin. The certs includes CN and SANs for the keyserver, so it could still be used in this scenario, actually. The SNI setups I've seen with deviating handling use e.g letsencrypt cert when doing direct keyserver request, but that would still validate. But you'd potentially also have issues with keydumps as well as split pools serving different keyblocks depending on which server you hit - so I believe the underlying question is more complex than just throwing https on it, although it is certainly possible to do so. Immediately it sounds like just increasing the overhead without much value added though (the data is public anyways), but the whole GDPR is a mess to begin with. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Expect the best. Prepare for the worst. Capitalize on what comes." (Zig Ziglar) signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Implications of GDPR
On 29/04/18 18:02, Ari Trachtenberg wrote: > In a two-stage process, the initial phase is done on hashes, and a > second stage transfers the data corresponding > to differing hashes. Yes, that's exactly what happens. The missing entries are fetched over a standard client request. > It should be possible for the second stage can be sent over an encrypted > tunnel without > too much effort. If the remote server supports HTTPS for client requests, then it would be straightforward for the reconciliation client to also connect over HTTPS - but it would have to either fall back to HTTP if the HTTPS request failed, or be configured with a list of which of its peers are HTTPS-enabled. Certificate validation may also be an issue, because many HTTPS pool members only have the pool SSL certificate - which won't validate in the normal manner when bypassing the pool round-robin. -- Andrew Gallagher signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Implications of GDPR
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
> On Apr 29, 2018, at 12:20 PM, Moritz Wirthwrote: > 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
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
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
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
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 <fsanti...@garbage-juice.com>; sks-devel <sks-devel@nongnu.org> 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
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