New keyserver at keys.openpgp.org - what's your take?

[Dirk Gottschalk]

Hello Vicent.

I read your explainations and will shorten them up to the points I want
to reply to.

Am Donnerstag, den 27.06.2019, 03:18 +0200 schrieb Vincent Breitmoser
via Gnupg-users:

> > (2) ‘processing’ means any operation or set of operations which is
> > performed
> > on personal data or on sets of personal data, whether or not by
> > automated
> > means, such as collection, recording, organisation, structuring,
> > storage,
> > adaptation or alteration, retrieval, consultation, use, disclosure
> > by
> > transmission, dissemination or otherwise making available,
> > alignment or
> > combination, restriction, erasure or destruction;

> This is most certainly what we are doing.

> So assuming that e-mail addresses are personal data, and we process
> this data, there is an (exhaustive!) list of possible situations in
> which we are lawfully allowed to do so, two of which can potentially
> apply. Article 6:

> > 1. Processing shall be lawful only if and to the extent that at
> > least one of the following applies:

> > (a) the data subject has given consent to the processing of his or
> > her
> >    personal data for one or more specific purposes;

> > (...)

> > (e) processing is necessary for the performance of a task carried
> > out in the public interest (...);

> The first is clear - if we have consent, we're good. The second
> *could* possibly be argued, but I have a hard time believing the
> haphazard handling of e-mail addresses on traditional keyservers
> serves the public interest. Even if we did assume this, there is the 

As one of the lawyers I work for told me, the consent could be
implicated by the users upload, therefor there must be the mechanism
that users can only upload their own keys, so consent is guaranteed.

> "right to object", which allows data subjects to object to the use of
> their data. Article 21:

> > 1. The data subject shall have the right to object, (...) to
> > processing of personal data concerning him or her which is based on
> > point (e) or (f) of Article 6(1), (...). The controller shall no
> > longer process the personal data unless the controller demonstrates
> > compelling legitimate grounds for the processing which override the
> > interests, rights and freedoms of the data subject (...).

> All in all, I find it pretty clear that GDPR does apply to processing
> of e-mail addresses on public keyservers. There are various nuanced
> conclusions one may draw, for example "it applies, but you probably
> won't get sued, so just keep on running them pool servers". It is
> unclear to me how one could look at this and conclude that keyservers
> aren't affected by GDPR.

The User knows how and why the data is processed, if he uploads his key
to the server. A deletion has to be possible by the regulation, SKS
lacks this mechanism. I haven't tested the new server yet, but I'm
planning to do this in the next day. As far as I read, deletion is
possible there.


> > and the, say, German implementation

> GDPR is a [regulation], not a [directive]. As such, it is an
> immediately enforcable law that does not require a per-country
> implementation to be effective.

Yes and no. The EU construct is a little bit strange in this manner,
but GDPR was transferred into german law by the renewal of the BDSG
last year.

> > along with relevant commentary to show why this is a legal
> > requirement.

> I'm aware of work on this by folks with legal background, but due to
> funny academic publishing culture I'm not at liberty to
> share. Hopefully something will be available to the public soon.

Oh yes, academic publishing culture is indeed a little strange. 

Regards,
Dirk

-- 
Dirk Gottschalk

GPG: 4278 1FCA 035A 9A63 4166  CE11 7544 0AD9 4996 F380
Keybase: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190628/1e1fbefa/attachment.sig>