Re: [Sks-devel] Implications of GDPR

2018-05-04 Thread Andrew Gallagher 

> On 4 May 2018, at 22:56, Arnold  wrote:
> 
> 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

2018-05-04 Thread Arnold 
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

2018-05-04 Thread dirk astrath 
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

2018-05-03 Thread brent s. 
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

2018-05-03 Thread Fabian A. Santiago 

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

2018-05-03 Thread Andrew Gallagher 
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

2018-05-03 Thread Kiss Gabor (Bitman) 
> 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

2018-05-03 Thread Moritz Wirth 
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 Trachtenberg  wrote:
> 
> … 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

2018-05-03 Thread Mike O'Connor 
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

2018-04-30 Thread Kristian Fiskerstrand 
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

2018-04-30 Thread Andrew Gallagher 
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

2018-04-29 Thread 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

2018-04-29 Thread 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

2018-04-29 Thread 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

2018-04-29 Thread 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

2018-04-29 Thread 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

2018-04-29 Thread 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 <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

2018-04-29 Thread 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

2018-04-29 Thread 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