Keyservers and GDPR

[Vincent Breitmoser]

Hey there,

(cross-posting on all the cool pgp lists)

so Dominik and I have been thinking a bit about how GDPR might affect
OpenKeychain, and its interoperability with public keyservers. Turns out this
is a hard question - in the end we couldn't answer whether publishing a tool
that offers keyserver interoperability really made us a "data controller"?

But let's start with keyservers first: "Processing" of data in the GDPR sense
includes storage and distribution. Names and email addresses are personally
identifiable information (PII). This makes the provider of a keyserver a data
processor in the sense of the GDPR.

Now, since the PII that is uploaded is not used to fulfill contractual
obligations, keyservers actually need informed consent from the user about what
is going to happen with that data. It's unclear how such consent might look
like given the API interface. But what's worse, in the current implementation
of SKS and the public keyserver pool, it is impossible by design to remove
a user's data once it is published. This conflicts with the "right to be
forgotten".

My personal conclusion is that keyservers that support user id packets are,
quite simply, incompatible with GDPR law. Has anyone else thought about this?
It's fairly unlikely that there will be actual consequences since keyservers
aren't widely used, but running a keyserver on this assumption is hardly
reassuring.

From the view of an app, the GDPR requires "privacy by design" and "privacy by
default". This conflicts with a workflow that asks the user for their email
address and name, and then irremovably uploads this information to a public
listing. On the other hand, it can be argued that this is a tool that only does
what the user asks it to do, the decision and responsibility lies with the user.
Looking at some extreme cases: a Browser surely doesn't take responsibility for
what the user inputs on websites. But a Twitter client does take responsibility
for informing the user when they publish their location in their tweets.

For OpenKeychain, we plan to move uploading of key material a bit farther out of
the way and do a better job at informing the user what's going to happen. But
that's a stopgap measure, since the user can't simply be asked to waive their
rights. Hopefully we can soon move away from keyservers for key discovery or
distribution.

Thoughts?

- V

PS: randomly signing this message /o/

[Bernhard Reiter]

Hi Vincent,

Post by Vincent Breitmoser
My personal conclusion is that keyservers that support user id packets are,
quite simply, incompatible with GDPR law. Has anyone else thought about this?

thinking about earlier data privacy laws (which were quite similiar to GDPR in
many respects) and pubkey servers got me to no clear conclusion.

Post by Vincent Breitmoser
For OpenKeychain, we plan to move uploading of key material a bit farther
out of the way and do a better job at informing the user what's going to
happen.

If our goal is to automate the common case in an end-to-end crypto
mail communication, then asking the user a data privacy agreement question
is a stumbling block. I would degrate the user experience a lot.

Note that if you use WKD with your email provider and just the email address
in the key id (as supported by a policy option), there is no additional
personal data saved nor communicated. The email provider already has your
email address and the person asking via WKD also. In addition serving of the
public key on behalf of ther user could be added to the terms of service
of the email provider. Overal I think WKD is doing quite well on the data
privacy side and will allow a good user experience by not asking each time to
publish a new pubkey for oneself.

Best Regards,
Bernhard

[Marcel Fest]

Post by Bernhard Reiter

Post by Vincent Breitmoser
My personal conclusion is that keyservers that support user id packets are,
quite simply, incompatible with GDPR law. Has anyone else thought about this?

thinking about earlier data privacy laws (which were quite similiar to GDPR in
many respects) and pubkey servers got me to no clear conclusion.

Post by Vincent Breitmoser
For OpenKeychain, we plan to move uploading of key material a bit farther
out of the way and do a better job at informing the user what's going to
happen.

If our goal is to automate the common case in an end-to-end crypto
mail communication, then asking the user a data privacy agreement question
is a stumbling block. I would degrate the user experience a lot.

What about keys uploaded by a third party without the consent
of the person concerned with his name and email addresses.

Best Regards

Marcel Fest

[Niels Dettenbach via Gnupg-devel]

Post by Marcel Fest
What about keys uploaded by a third party without the consent
of the person concerned with his name and email addresses.

I see this as part of the specs.

If it makes any sense to build a feature allow to mark "public" keys as "non
public" this would be a technical question.

[Christoph Anton Mitterer]

On Wed, 2018-05-23 at 12:12 +0200, Niels Dettenbach via Gnupg-devel

Post by Niels Dettenbach via Gnupg-devel
If it makes any sense to build a feature allow to mark "public" keys as "non
public" this would be a technical question.

But that has the same problem as deleting keys...

It mustn't be done for security reasons, as otherwise attackers could
remove any revocations from the keyservers.


Cheers,
Chris.

[Dirk Gottschalk via Gnupg-devel]

Hi.

Am Mittwoch, den 23.05.2018, 13:16 +0200 schrieb Christoph Anton

Post by Christoph Anton Mitterer
On Wed, 2018-05-23 at 12:12 +0200, Niels Dettenbach via Gnupg-devel

Post by Niels Dettenbach via Gnupg-devel
If it makes any sense to build a feature allow to mark "public"
keys
as "non
public" this would be a technical question.

But that has the same problem as deleting keys...
It mustn't be done for security reasons, as otherwise attackers could
remove any revocations from the keyservers.

Well, that's true. the only option would be to allow only the key owner
to upload or delete his key and allow other users only to attach new
signatures or something like this. Revocation should also only be
possible by the owner or a permitted revoker.

But this would cause massive protocol changes and this would take it's
time.

On the other hand, I don't see any Problems with GDPR at all. I don't
think that they even thought about such cases. The most protocols would
be no longer legal after it takes place. ^^

GDPR is, just IMHO, an epic Fail and does not address reality. It is
usable for Websites, but nothing else. There woud have to be so much
exceptions for every protocol, that the list of exceptions would be
loinger than the GDPR itself. ^^

Regards,
Dirk

[Christoph Anton Mitterer]

On Wed, 2018-05-23 at 15:31 +0200, Dirk Gottschalk via Gnupg-devel

Post by Dirk Gottschalk via Gnupg-devel
Well, that's true. the only option would be to allow only the key owner
to upload or delete his key

That would in fact be a good thing... perhaps even with some form of
challenge response (i.e. the owner must sign something as a response).

In addition.... it should be possible for a key owner, to delete his
UID subpackets from the keyservers... (any revoc subpackets/etc. should
be kept forever).

But in fact even this may not be fully enough to fulfil that stupid EU
laws.

Post by Dirk Gottschalk via Gnupg-devel
On the other hand, I don't see any Problems with GDPR at all. I don't
think that they even thought about such cases. The most protocols would
be no longer legal after it takes place. ^^

I'm not an expert... but from my naive understanding I'd say that the
GDPR basically outlaws keyservers as they're now.


I've stopped mine for now.


Cheers,
Chris.

[Kristian Fiskerstrand]

Post by Christoph Anton Mitterer
That would in fact be a good thing... perhaps even with some form of
challenge response (i.e. the owner must sign something as a response).

yes and no.. it basically changes keyservers to becoming certificate
authorities. And unless they do signature / certification on the
keyblock this state isn't kept anywhere.. but it is basically the PGP
Global Directory.

From a security perspective I'm not impressed about it, and there are
several caveats, in particular related to expecting a domain name being
in the original owner's control forever. So revocation of a previous
owner wouldn't be recorded. It also excludes any non-email UIDs, e.g
just a plain name or a pseudonym/handle in other channels (twitter?)
--
----------------------------
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
----------------------------
"Be a yardstick of quality. Some people aren't used to an environment
where excellence is expected."
(Steve Jobs)

[Andrew Gallagher]

Post by Kristian Fiskerstrand
It also excludes any non-email UIDs, e.g
just a plain name or a pseudonym/handle in other channels (twitter?)

Or monkeysphere ssh host keys...

A

[Christoph Anton Mitterer]

Post by Kristian Fiskerstrand
yes and no.. it basically changes keyservers to becoming certificate
authorities.

?? Why this?

A CA is trusted by others and assures the identity of subjects.
The challenge/response I'm talking about, would just assure that only
the owner can publish the key to the network.
It would in no way make any assurance about the identity.

Post by Kristian Fiskerstrand
And unless they do signature / certification on the
keyblock this state isn't kept anywhere..

Sure... it's just the proof, that the owner of the key actually wishes
its publication.

Of course the owner could still set up a fake User ID, effectively
publishing another user's personal data.. but I guess then we'd be save
in terms of privacy laws.

Post by Kristian Fiskerstrand
but it is basically the PGP
Global Directory.

I don't think PGP GD requires prof that an uploader is the key owner.
The only difference with that is that it doesn't syncronise with other
keyservers (which is a major deficiency from a security PoV)... and
didn't it remove keys after a while (if the users didn't reupload)..
but then removal is complete (IIRC)... which is again a major
deficiency, as revocations are also removed.

Post by Kristian Fiskerstrand
From a security perspective I'm not impressed about it, and there are
several caveats, in particular related to expecting a domain name being
in the original owner's control forever

You mean the PGP GD model? Well I haven't said we should do it as they
do it (i.e. sending a mail to people asking them for reupload)...
instead... if a user wants to keep his UIDs published, his client would
need to do the reupload every now and then.. say once a year.
If he doesn't,... the UIDs would get removed from the keyserver network
(but NOT the revocation sigs).

I'm not sure whether other sigs on the key should be removed
(especially thinking about the certifcation sigs the person of the
removed key made on other people)... these could basically allow to
"trace" his contacts... and may therefore interfere with privacy laws.
OTOH... when the UIDs are gone... it's already pseudo-anonymous... so
might be fine.

Post by Kristian Fiskerstrand
So revocation of a previous
owner wouldn't be recorded. It also excludes any non-email UIDs, e.g
just a plain name or a pseudonym/handle in other channels (twitter?)

As said above... I don't think challenge/response should be like PGP GD
does it with sending mails. This would also impose much more burden on
the keyservers (and even more legal risks... "unwanted mail" and so
on).
I'd rather think about: when some person wants to upload its key... its
client must attach a signed standardised message like:
"I herby certify that this is my key, my own valid identities and that
I allow it to published globally to all servers of the SKS keyserver
network for 1 year or until I revoke permission. Even then, only the
UserIDs will be removed and all other data remains. <current
date/time>."
(Some lawyer should draft a suitable text)

And only if the current date/time is in a +/- 30 min time frame... and
if the sig validates... the keyserver would accept the UIDs.


The whole thing would *not* apply to just upgrades... like new
certification sigs.


Cheers,
Chris.

[Ben McGinnes]

Post by Christoph Anton Mitterer

Post by Kristian Fiskerstrand
yes and no.. it basically changes keyservers to becoming certificate
authorities.

?? Why this?
A CA is trusted by others and assures the identity of subjects.
The challenge/response I'm talking about, would just assure that only
the owner can publish the key to the network.

I take it you just mean something like signing a token with the key
you're trying to upload? Sure, assuming it doesn't also prevent
signature updates, for all the obvious reasons.

Post by Christoph Anton Mitterer
Of course the owner could still set up a fake User ID, effectively
publishing another user's personal data.. but I guess then we'd be
save in terms of privacy laws.

Post by Kristian Fiskerstrand
but it is basically the PGP
Global Directory.

I don't think PGP GD requires prof that an uploader is the key owner.
The only difference with that is that it doesn't syncronise with other
keyservers (which is a major deficiency from a security PoV)... and
didn't it remove keys after a while (if the users didn't reupload)..
but then removal is complete (IIRC)... which is again a major
deficiency, as revocations are also removed.

Post by Kristian Fiskerstrand
From a security perspective I'm not impressed about it, and there are
several caveats, in particular related to expecting a domain name being
in the original owner's control forever

You mean the PGP GD model? Well I haven't said we should do it as
they do it (i.e. sending a mail to people asking them for
reupload)...

Good, it does get a bit ridiculous and the load would be a bit silly.

Post by Christoph Anton Mitterer
instead... if a user wants to keep his UIDs published,
his client would need to do the reupload every now and then.. say
once a year. If he doesn't,... the UIDs would get removed from the
keyserver network (but NOT the revocation sigs).

Hang on, you're proposing the keyservers edit keys that aren't updated
to remove the UIDs?

Two questions:

1. How could end users continue to trust the servers knowing that
their key data may be edited at all? For instance if law
enforcement want to isolate a person from contact and issue some
kind of compliance order to remove the UIDs since there's
precendent, what then?

2. How would you actually update this when resynchronising with other
servers will simply (or should simply) restore that data?

Post by Christoph Anton Mitterer
I'm not sure whether other sigs on the key should be removed

They should not, only the person/entity making the signature should be
modifying it.

Post by Christoph Anton Mitterer
(especially thinking about the certifcation sigs the person of the
removed key made on other people)... these could basically allow to
"trace" his contacts... and may therefore interfere with privacy
laws. OTOH... when the UIDs are gone... it's already
pseudo-anonymous... so might be fine.

You're already veering into dangerous enough territory with any kind
of key modification as it is.

Post by Christoph Anton Mitterer
I'd rather think about: when some person wants to upload its key... its

[SNIP]

Post by Christoph Anton Mitterer
And only if the current date/time is in a +/- 30 min time frame... and
if the sig validates... the keyserver would accept the UIDs.

This bit I kind of don't mind.

Post by Christoph Anton Mitterer
The whole thing would *not* apply to just upgrades... like new
certification sigs.

Presumably it would apply to adding and revoking subkeys, the UIDs,
modifying any expiration times of the primary key or subkeys, changes
to cipher, digest and algorithm preferences (including cert-digest)
and so on, but *not* to the addition of signatures or revocation of
the same.

Deletion of data should not be permitted because it opens the entire
nework up to a whole slew of attacks and legal vulnerabilities which
would be rather bad.


Regards,
Ben

[Niels Dettenbach (Syndicat IT & Internet) via Gnupg-devel]

Post by Vincent Breitmoser
Now, since the PII that is uploaded is not used to fulfill contractual
obligations

I'm not a lawyer, but i see this vice versa.

Users upload their keys for the purpose of their usage in the "web of trust" and expect their availability (storage, processing)there for this.

A contract with the server owner/admin IS emerged with the transfer of the data in the conventional keyserver protocol without any further "written" contract.

Extended, written explicite order is required if the keyserver (their owner) want to use that data for other purposes, not covered by the specs.

This is my view. But clearifying this needs a good las expert with a good understanding in the specs and the whole process.


just my two cents.

Niels.

[Patrick Brunschwig]

On 22.05.18 21:44, Vincent Breitmoser wrote:
[...]

Post by Vincent Breitmoser
My personal conclusion is that keyservers that support user id packets are,
quite simply, incompatible with GDPR law. Has anyone else thought about this?
It's fairly unlikely that there will be actual consequences since keyservers
aren't widely used, but running a keyserver on this assumption is hardly
reassuring.

There are actually two different types of keyservers, which should be
clearly distinguished.

1. the pool of SKS keyservers: as anyone can upload anybody's key, and
as it does not allow to delete keys, it's IMHO by not compatible with GDPR.

2. other types of keyservers like the run by Mailvelope (and possibly
others that I don't know of), that verify the keys they receive and
allow to delete keys, are compatible with GDPR, or can be made
compatible easily.

-Patrick

[Andrew Gallagher]

I'm not of the opinion that key servers are a good idea at all. It's
a pity that people still follow this wrong idea.

There are other methods for discovery that don’t suffer from the same weaknesses, but there is no equally resilient method of distributing revocations.

A

[Werner Koch]

I'm not of the opinion that key servers are a good idea at all. It's
a pity that people still follow this wrong idea.

Keyservers are used for several purposes:

1. Search for keys based on the fingerprint ("gpg --recv-key FPR")
2. Search for key recovations ("gpg --refresh-key")
3. Search for keys based on the user id. (e.g. "gpg --search-key")
4. As a distribution medium for key signatures.
5. As a distributed and searchable storage.

The first two purposes are quite useful because they allow to verify
signatures made by yet unknown keys. Retrieving the keys is no data
privacy problem because by signing and sending a mail the sender has
already provided all these information. There is nothing which can
replace these purposes because a key does not necessary need to have a
mail address and even if so, any mail address based lookup can fail
after the mail address is not longer in use, the account has been
disabled, etc. Fingerprints are are globally unique and need not be
associated with a mail address.

Purpose 3 is what we call key discovery and indeed keyservers are the
wrong way to do this. In most cases we want to map a mail address to a
key and have some kind of reliable mapping. Keyservers which are just a
pile of keys don't allow for this. Back then when encryption was young
and the internet was a friendly place search for keys worked in most
cases. But the times have changed and the bona fide search is useless.

Purpose 4, distribution of key signatures, worked as long as people
didn't used the key listings of the server or tools for more or less
funny messages. Uploading key signature should be possible only by the
holder of the key. However, to enforce this the keyservers need to
employ real crypto and won't be a lean service anymore. I think the
distribution of keyservers, for those who still want to use the WoT,
can be replaced by sending the signed keys only back to owner. In fact
tools like caff suggest this use case.

Purpose 5 is not relevant for OpenPGP key distribution and actually the
reason why the keyserver network has more or less broken down.

My suggestion is limit the keyservers to the purposes 1 and 2. This
can in practice easily be done by removing the search by user-id
interface form the keyservers and, on the client site, by discovering
keys using other methods (e.g. Web Key Directory). Having no searchable
interface to the keyservers make them less attractive for abuse (as in
purpose 5) and avoid some privacy issues (white pages without user
consent).

It is likely that gpg will eventually change its --search-key command to
do the equivalent of --locate-key but without checking the local
keyring.


Salam-Shalom,

Werner

[Andrew Gallagher]

World-writable storage is problematic even if there is no search.
Proof of work and some operator-controllable data removal
mechanism (like opt-in key blacklists) can help limit this attack
vector.
Storing immutable data, distributed recon, proof of work, that
sounds like something a blockchain should do to me.

More evidence that blockchain is a solution in search of a problem! :-)

Proof of work verification provides little benefit over cryptographic verification. If you have already generated a valid signature, that is in itself a proof of work. The only reason you would also use hashcash is if you wanted to increase the difficulty of the work beyond what the cryptography itself provides. But hashcash only works if it is possible to find a difficulty level that impedes abuse while not significantly affecting legitimate use. It may stop people uploading warez but it can’t prevent cheap vandalism.

A

[Wiktor Kwapisiewicz via Gnupg-devel]

Post by Andrew Gallagher

World-writable storage is problematic even if there is no search.
Proof of work and some operator-controllable data removal
mechanism (like opt-in key blacklists) can help limit this attack
vector.
Storing immutable data, distributed recon, proof of work, that
sounds like something a blockchain should do to me.

More evidence that blockchain is a solution in search of a problem! :-)
Proof of work verification provides little benefit over cryptographic verification. If you have already generated a valid signature, that is in itself a proof of work. The only reason you would also use hashcash is if you wanted to increase the difficulty of the work beyond what the cryptography itself provides. But hashcash only works if it is possible to find a difficulty level that impedes abuse while not significantly affecting legitimate use. It may stop people uploading warez but it can’t prevent cheap vandalism.

Blockchain can be used to timestamp data in a way that is evident to a
broad audience. If cryptographic verification was enough for X.509 there
wouldn't be Certificate Transparency (that uses similar primitives) and
CT is required for all issued "SSL certificates" today [0].

For OpenPGP that would mean keeping the keyservers accountable: not
letting them return different responses for different people, or
omitting some data (e.g. revocations).

There are already projects that tackle this very problem:
- https://coniks.cs.princeton.edu/about.html
-
https://security.googleblog.com/2017/01/security-through-transparency.html
-
https://blog.okturtles.org/2017/02/coniks-vs-key-transparency-vs-certificate-transparency-vs-blockchains/

(For the record I'm not advocating for using blockchain, but even a
buzzword tech should be evaluated purely on its merits)

Kind regards,
Wiktor

[0]:
https://www.thesslstore.com/blog/certificate-transparency-april-30-2018/

[Tobias Mueller]

Hi,

On Wed, 2018-11-07 at 12:33 +0100, Wiktor Kwapisiewicz via Autocrypt

Post by Wiktor Kwapisiewicz via Gnupg-devel
If cryptographic verification was enough for X.509 there
wouldn't be Certificate Transparency

CT solves a slightly different set of problems related to
the centralised trust model that we don't necessarily have.

That said, I think we can store revocations in the CT logs s.t. we can
at least have integrity protection and non-equivocation for those. Both
properties which we currently do not have when fetching them from the
key server.


Cheers,
Tobi

[Wiktor Kwapisiewicz via Gnupg-devel]

Hello,

Post by Tobias Mueller
That said, I think we can store revocations in the CT logs s.t. we can
at least have integrity protection and non-equivocation for those. Both
properties which we currently do not have when fetching them from the
key server.

Mozilla experimented with storing release hashes of Firefox in CT logs:
https://wiki.mozilla.org/Security/Binary_Transparency

They used Merkle tree so the amount of data stored is small (just the
tree head) compared to the OpenPGP revocation.

Kind regards,
Wiktor

[Werner Koch]

Post by Andrew Gallagher
significantly affecting legitimate use. It may stop people uploading
warez but it can’t prevent cheap vandalism.

Free storage to upload arbitrary data is easily available (e.g. p2p,
free mail accounts). Having a searchable index to that data is more
challenging. Thus removing the search capability from the keyservers
will render its free-as-in-beer storage feature mostly useless.


Salam-Shalom,

Werner

[Tobias Mueller]

Post by Werner Koch
Thus removing the search capability from the keyservers
will render its free-as-in-beer storage feature mostly useless.

Only if you assume that nobody creates such an index.

Cheers,
Tobi

[Werner Koch]

Post by Tobias Mueller
Only if you assume that nobody creates such an index.

But then it is not a problem for keyserver operators (except for load
issues).


Salam-Shalom,

Werner

[Andrew Gallagher]

It's not just storage, it's also immutable and distributed.

In the keyservers, removing immutable content is a Very Hard Problem, but it is theoretically possible.

With blockchain, it is impossible by design.

A

[Werner Koch]

I do roughly recal that such a verification process has been discussed for
the SKS keyservers at one of the pgp-summit before, but i wonder what
happened to the idea. However, if it that is “good enough” to be compliant

This requires that there are no rogue keyservers in the network and that
in turn means that they are under the control of a single entity. Or
in short, let Google take care of it.

Such verification will be a single point of failure and it would be
trivial for governments or corporations to take down a key.


Shalom-Salam,

Werner

[Tobias Mueller]

Hi,

Post by Werner Koch
This requires that there are no rogue keyservers in the network and that
in turn means that they are under the control of a single entity.

It depends on your use case, but you might be happy enough if you have a
proof of who introduced the malicious data.

That said, you might as well establish a network adhering to certain
rules run by people who are trusted enough by its users. That may not
necessarily be Google, but the EFF, the CCC, or the DPAs of the EU
member states.

Cheers,
Tobi

[ilf]

tl;dr: Keep calm and keep running keyservers.

Post by Vincent Breitmoser
(cross-posting on all the cool pgp lists)

(I wonder, if this really needs to be an all the four lists. I think
sks-devel@ might be the most appropriate. Having said that, I'm only
replying to gnupg-devel@ because I'm not subscribed to sks-***@. Feel
free to relay my message.)

Post by Vincent Breitmoser
My personal conclusion is that keyservers that support user id packets
are, quite simply, incompatible with GDPR law.

There is a ton of FUD about the GDPR out there right now. Most of it
frivolous. (Actually, a lot of it is deliberate fearmongering by people
who happen to sell legal advice on the GDPR.)

First of all, the GDPR is not completely new. All EU member states
already have data protection laws, some - like Germany - already very
strong ones. The concepts (PII, responsibilities, technological and
organisational measures, information and documentation obligations) have
already been in place with the old Data Protection Directive from 1995,
which the GDPR is updating. I admit that the GDPR can be read and
interpreted in a fatalist way. But most people leaning that way seem to
not have read the older laws.

Laws are not set in stone. Laws include leeways, deliberate or
unintended. Laws do not depend on their interpretation by laypeople.
There is a huge dedicated system for its interpretation, conflict
resolve, judgement and enforcement.

In the case of the GDPR, the very first step of that system are National
Data Protection Authorities (DPA). They have the power - and the
responsibility - to investigate possible violations of the GDPR. They
have been understaffed for years, in many countries dangerously so. They
are getting a lot more powers and responsibilities with the GDPR, but
their resources are growing way slower than their tasks. They are
simply understaffed and overworked. So from all the possible GDPR
violations they will be notified about, they will work off the biggest
and most obvious ones first. Their focus will be on the Facebooks - and
not on small nerd projects or personal websites. They have the power to
say "we don't care about this weird thing called keyserver" - and the
probably will.

Now even if someone found data protection law infringements with a
keyserver, filed a specific and well-worded legal complaint with a DPA,
and a DPA found the resources to look into it, and the DPA found some
violation of the GDPR (four big IFs!) - the DPAs will not go around and
issue sanctions and fine people. First of all, their job is not to
generate revenues by fines. Their job is to enforce data protection law.
If a DPA did find an issue with a keyserver - or the very concept - they
would reach out and talk to the people running the servers. They would
hear their perspective, learn more about the very concept - and try to
work out a viable solution to provide the service without possible data
protection infringements. This is their job and their goal.

The most feared sanction of some undefined GDPR violation is a fine. As
I layed out, DPAs don't want to issue fines, they want to stop privacy
violations. And they will not blindly issue a fine without talking to
you first. That being said, they obviously do have the power to issue
fines. After due process. However, this power is also not new, it has
also existed in many countries. And DPAs don't run around and fine
people left and right (you would have heard about that), they exercise
their power in a balanced way. And fines are always in relation to the
economic and personal circumstances of the - then guilty and obstinate -
data protection violators. I guess most keyservers are run by
non-profit individuals or institutions. Even if a company runs a
keyserver, it doesn't make money with that service. Therefore, I think
the chance of *any* fine is negligible - and the chance of an
unreasonably high fine is almost zero. And if it ever came to this, the
community and public alarmed by public outcry would probably donate more
than the fine issued.

To sum up: Keep calm and keep running keyservers. You'll be fine.

More elaboration in German:
https://netzpolitik.org/2018/bussgelder-bei-datenschutzverstoessen-angst-vor-einem-phantom/

Disclaimer: IANAL. This is not legal advice.

[ilf]

Post by ilf
To sum up: Keep calm and keep running keyservers. You'll be fine.

I forgot one point: The one thing you *should* take care about is to
publish a privacy statement on your keyservers website, listing the data
your server logs. There are a lot of templates out there, a popular
German one is https://datenschutz-generator.de/ (so pupolar it seems
overloaded).

[Kristian Fiskerstrand]

Post by ilf
tl;dr: Keep calm and keep running keyservers.

Post by Vincent Breitmoser
(cross-posting on all the cool pgp lists)

(I wonder, if this really needs to be an all the four lists. I think
free to relay my message.)

As I think this has a valuable viewpoint I'm posting it to sks-devel.
And yes, this is mostly in line with my own thinking, I don't expect the
need for radical changes unless we see actual attempts to go after the
infrastructure.

Post by ilf

Post by Vincent Breitmoser
My personal conclusion is that keyservers that support user id packets
are, quite simply, incompatible with GDPR law.

There is a ton of FUD about the GDPR out there right now. Most of it   
frivolous. (Actually, a lot of it is deliberate fearmongering by people
who happen to sell legal advice on the GDPR.)
First of all, the GDPR is not completely new. All EU member states
already have data protection laws, some - like Germany - already very 
strong ones. The concepts (PII, responsibilities, technological and
organisational measures, information and documentation obligations) have
already been in place with the old Data Protection Directive from 1995,
which the GDPR is updating. I admit that the GDPR can be read and
interpreted in a fatalist way. But most people leaning that way seem to
not have read the older laws.
Laws are not set in stone. Laws include leeways, deliberate or
unintended. Laws do not depend on their interpretation by laypeople.
There is a huge dedicated system for its interpretation, conflict
resolve, judgement and enforcement.
In the case of the GDPR, the very first step of that system are National
Data Protection Authorities (DPA). They have the power - and the
responsibility - to investigate possible violations of the GDPR. They
have been understaffed for years, in many countries dangerously so. They
are getting a lot more powers and responsibilities with the GDPR, but
their resources are growing way slower than their tasks. They are simply
understaffed and overworked. So from all the possible GDPR violations
they will be notified about, they will work off the biggest and most
obvious ones first. Their focus will be on the Facebooks - and not on
small nerd projects or personal websites. They have the power to say "we
don't care about this weird thing called keyserver" - and the probably
will.
Now even if someone found data protection law infringements with a
keyserver, filed a specific and well-worded legal complaint with a DPA,
and a DPA found the resources to look into it, and the DPA found some
violation of the GDPR (four big IFs!) - the DPAs will not go around and
issue sanctions and fine people. First of all, their job is not to
generate revenues by fines. Their job is to enforce data protection law.
If a DPA did find an issue with a keyserver - or the very concept - they
would reach out and talk to the people running the servers. They would
hear their perspective, learn more about the very concept - and try to
work out a viable solution to provide the service without possible data
protection infringements. This is their job and their goal.
The most feared sanction of some undefined GDPR violation is a fine. As
I layed out, DPAs don't want to issue fines, they want to stop privacy
violations. And they will not blindly issue a fine without talking to
you first. That being said, they obviously do have the power to issue
fines. After due process. However, this power is also not new, it has
also existed in many countries. And DPAs don't run around and fine
people left and right (you would have heard about that), they exercise
their power in a balanced way. And fines are always in relation to the
economic and personal circumstances of the - then guilty and obstinate -
data protection violators. I guess most keyservers are run by 
non-profit individuals or institutions. Even if a company runs a
keyserver, it doesn't make money with that service. Therefore, I think
the chance of *any* fine is negligible - and the chance of an
unreasonably high fine is almost zero. And if it ever came to this, the
community and public alarmed by public outcry would probably donate more
than the fine issued.
To sum up: Keep calm and keep running keyservers. You'll be fine.
https://netzpolitik.org/2018/bussgelder-bei-datenschutzverstoessen-angst-vor-einem-phantom/
Disclaimer: IANAL. This is not legal advice.
_______________________________________________
Gnupg-devel mailing list
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

--
----------------------------
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
----------------------------
"I disapprove of what you say, but I will defend to the death your right
to say it."
Evelyn Beatrice Hall (summarizing Voltaire

[Ben McGinnes]

Post by ilf
There is a ton of FUD about the GDPR out there right now. Most of it
frivolous. (Actually, a lot of it is deliberate fearmongering by
people who happen to sell legal advice on the GDPR.)

Somehow this comes as absolutely no surprise whatsoever.

Post by ilf
To sum up: Keep calm and keep running keyservers. You'll be fine.

Thanks for an excellent practical overview of the background of the
law and what it's building on.

That's the kind of information which is not really known by most
people outside of the EU and so we're all just hearing "new law and it
must be followed outside of the EU if it affects anyone inside the EU"
(on pain of fines and/or total geo-blocking or whatever). There's a
*lot* of panic in other FOSS projects as well, which this explanation
shows really is based on that kind of FUD.

I believe I may be using the list archive's URL for your post (and the
privacy data usage statement follow-up) to at least try to help calm a
few people down. 😉


Regards,
Ben

[ilf]

But what's worse, in the current implementation of SKS and the public
keyserver pool, it is impossible by design to remove a user's data
once it is published. This conflicts with the "right to be forgotten".

The right-to-be-forgotten (RTBF) and the design of append-only logs like
keyservers and blockchain™ obviously present a challenge on how to
combine both. But this is also nothing to panic about. Especially since
virtually all German DPAs use OpenPGP themselves:

https://www.bfdi.bund.de/SharedDocs/Publikationen/BfDIKey.asc?__blob=publicationFile&v=1
https://www.lda.bayern.de/media/pgp_schluessel_dsa.asc
https://www.datenschutz-berlin.de/email/mailbox_blnbdi.asc
http://www.lda.brandenburg.de/media_fast/4055/LDABbgpublickey.asc
https://www.datenschutz-hamburg.de/fileadmin/user_upload/documents/pgp-schluessel_hmbbfdi.asc
https://datenschutz.hessen.de/sites/datenschutz.hessen.de/files/PGP-Schluessel.txt
https://www.datenschutz-mv.de/static/DS/Dateien/pgp_lds_mv.asc
https://www.lfd.niedersachsen.de/download/32009/Unser_PGP-Schluessel_neu_ab_01.09.2015_.txt
https://www.ldi.nrw.de/metanavi_Kontakt/key_ldi.asc
https://www.datenschutz.rlp.de/fileadmin/lfdi/Dokumente/pubkey_lfdi-rlp.asc
https://datenschutz.saarland.de/fileadmin/pgp/datenschutzzentrum-key_.asc
https://www.saechsdsb.de/images/stories/sdb_inhalt/behoerde/SaechsDSB.txt
https://www.datenschutzzentrum.de/uploads/uld/uld.asc
https://www.tlfdi.de/mam/tlfdi/start/tlfdi_schluessel_ab_dez_2015.txt

Also, all of those keys are also on the keyserver pool. As they should
be. I just "checked". :)

Again: Don't panic.

[Andrew Gallagher]

Post by ilf
Again: Don't panic

There are several grounds for handling data other than explicit user
consent, but more importantly the legal bar is "reasonable effort" and
not "absolute compliance". It is unlikely that keyservers will be first
in line, so let's keep one eye on the newspapers and see how it goes.

I'm more concerned about the prospect of child porn image IDs. Let's
deal with that one first.

(IANAL, etc.)