Mailing List Archive

Keyservers and GDPR
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/
Re: Keyservers and GDPR [ In reply to ]
Am 22. Mai 2018 21:44:09 MESZ schrieb Vincent Breitmoser <look@my.amazin.horse>:
>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.

--
Niels Dettenbach
Syndicat IT & Internet
http://www.Syndicat.com

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Keyservers and GDPR [ In reply to ]
Hi Vincent,

Am Dienstag 22 Mai 2018 21:44:09 schrieb 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.

> 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

--
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Re: Keyservers and GDPR [ In reply to ]
>> 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.
>
>> 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
Re: Keyservers and GDPR [ In reply to ]
On 22.05.18 21:44, Vincent Breitmoser wrote:
[...]
> 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

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Keyservers and GDPR [ In reply to ]
tl;dr: Keep calm and keep running keyservers.

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-devel@. Feel
free to relay my message.)

> 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

If you upload your address book to "the cloud", I don't want to be in it.
Re: Keyservers and GDPR [ In reply to ]
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).

--
ilf

If you upload your address book to "the cloud", I don't want to be in it.
Re: Keyservers and GDPR [ In reply to ]
On 05/23/2018 11:27 AM, ilf wrote:
> tl;dr: Keep calm and keep running keyservers.
>
> 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-devel@. Feel
> 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.

>
>> 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.
>
>
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel@gnupg.org
> 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
Re: Keyservers and GDPR [ In reply to ]
Am Mittwoch, 23. Mai 2018, 10:29:10 CEST schrieb 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.


--
---
Niels Dettenbach
Syndicat IT & Internet
http://www.syndicat.com
PGP: https://syndicat.com/pub_key.asc
---
Re: Keyservers and GDPR [ In reply to ]
On Wed, 2018-05-23 at 12:12 +0200, Niels Dettenbach via Gnupg-devel
wrote:
> 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.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Keyservers and GDPR [ In reply to ]
Hi.

Am Mittwoch, den 23.05.2018, 13:16 +0200 schrieb Christoph Anton
Mitterer:
> On Wed, 2018-05-23 at 12:12 +0200, Niels Dettenbach via Gnupg-devel
> wrote:
> > 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


--
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen
Tel.: +49 1573 1152350
Re: [Autocrypt] Keyservers and GDPR [ In reply to ]
Vincent Breitmoser:
> 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.

--
ilf

If you upload your address book to "the cloud", I don't want to be in it.
Re: [Autocrypt] Keyservers and GDPR [ In reply to ]
On 23/05/18 14:40, ilf wrote:
>
> 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.)

--
Andrew Gallagher
Re: Keyservers and GDPR [ In reply to ]
On Wed, 2018-05-23 at 15:31 +0200, Dirk Gottschalk via Gnupg-devel
wrote:
> 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.


> 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.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Keyservers and GDPR [ In reply to ]
On 05/23/2018 11:04 PM, Christoph Anton Mitterer wrote:
> 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)
Re: Keyservers and GDPR [ In reply to ]
> On 23 May 2018, at 22:45, Kristian Fiskerstrand <kristian.fiskerstrand@sumptuouscapital.com> wrote:
>
> 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

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Keyservers and GDPR [ In reply to ]
On Wed, 2018-05-23 at 23:45 +0200, Kristian Fiskerstrand wrote:
> 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.


> 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.


> 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.



> 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.


> 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.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Keyservers and GDPR [ In reply to ]
On Wed, May 23, 2018 at 11:27:15AM +0200, ilf wrote:
>
> 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.

> 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
Re: Keyservers and GDPR [ In reply to ]
On Thu, May 24, 2018 at 12:42:12AM +0200, Christoph Anton Mitterer wrote:
> On Wed, 2018-05-23 at 23:45 +0200, Kristian Fiskerstrand wrote:
> > 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.

> 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.
>
>
> > 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.
>
>
>
> > 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.

> 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?

> 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.

> (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.

> I'd rather think about: when some person wants to upload its key... its
> client must attach a signed standardised message like:
[SNIP]
> 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.

> 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
Re: Keyservers and GDPR [ In reply to ]
Almost one year ago, there was a big debate about the GDPR and
keyservers.

Now I would like to know: Did any keyserver admin(s) receive any
(serious) GDPR-related complaint? Or even an official complaint by a
data protection authority? Or even a penalty like a fine?

I assume not, at least for the latter two.

The fines by German DPAs have been rather low:
https://www.welt.de/finanzen/article193326155/DSGVO-Verstoesse-Bundeslaender-ziehen-Bussgeld-Bilanz.html

So far, I stand by last year's statement:

> tl;dr: Keep calm and keep running keyservers.

--
ilf

If you upload your address book to "the cloud", I don't want to be in it.
Re: Keyservers and GDPR [ In reply to ]
FTR: I have not received a single reply. Happy GDPR day :)

ilf:
> Now I would like to know: Did any keyserver admin(s) receive any
> (serious) GDPR-related complaint? Or even an official complaint by a
> data protection authority? Or even a penalty like a fine?

--
ilf

If you upload your address book to "the cloud", I don't want to be in it.
Re: Keyservers and GDPR [ In reply to ]
On Sat, 25 May 2019 14:53, ilf@zeromail.org said:

> ilf:
>> Now I would like to know: Did any keyserver admin(s) receive any
>> (serious) GDPR-related complaint? Or even an official complaint by a
>> data protection authority? Or even a penalty like a fine?

You mean from the left over 5 servers in the default hkps pool:

pgpkeys.eu 51.38.91.189 AS16276 (UK)
pgpkeys.uk 192.146.137.98 AS57672 (UK)
pgpkeys.co.uk 192.146.137.99 AS57672 (UK)
fks.pgpkeys.eu 46.4.246.179 AS24940 (DE, Hetzner)
keys2.kfwebs.net 37.191.231.105 AS57963 (NO)

which according to rumours have only two or three different operators?


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Keyservers and GDPR [ In reply to ]
On 2019-05-26 at 10:43 +0200, Werner Koch wrote:
> On Sat, 25 May 2019 14:53, ilf@zeromail.org said:
> You mean from the left over 5 servers in the default hkps pool:
>
> pgpkeys.eu 51.38.91.189 AS16276 (UK)
> pgpkeys.uk 192.146.137.98 AS57672 (UK)
> pgpkeys.co.uk 192.146.137.99 AS57672 (UK)
> fks.pgpkeys.eu 46.4.246.179 AS24940 (DE, Hetzner)
> keys2.kfwebs.net 37.191.231.105 AS57963 (NO)
>
> which according to rumours have only two or three different operators?

My old SKS membership file had both pgpkeys.co.uk and pgpkeys.eu
maintained by Daniel Austin; the off-by-one for pgpkeys.uk suggests
Daniel runs that one too. That covers the first four.

kfwebs.net is Kristian Fiskerstrand, who runs the pool tracking system
and sks-keyservers.net.

hkps is limited because Kristian doesn't hand out certs to anyone who
shows up with a new keyserver and asks; he tends to do so with people
who've been around and part of the community, because of the fairly
obvious problems with assuming TLS is buying you anything when entirely
unknown-to-others folks run the servers. Kristian takes a lot of flak
for not giving people the power they want just because they ask for it.

With the various problems of SKS today, I tentatively suggest that not
defaulting to the HKPS pool and choosing a different target for the
keys.gnupg.net CNAME might be beneficial.

<https://sks-keyservers.net/overview-of-pools.php> has the criteria; I
suspect that >> subset.pool.sks-keyservers.net << is likely to be the
best choice for GnuPG; the meaning of "subset" changes over time,
picking newer servers, but for a while now that's been "updated SKS
software able to handle Curve25519 keys".

Spitballing crazy design now:

The only way to get back HKPS while still having diversity and yet still
some accountability is likely to be by requiring DNSSEC-signed
reverse-DNS which points to matching DNSSEC-signed forward DNS to prove
domain matching, and a trigger record in DNS indicating to use TLS; once
there's a forward-name which doesn't require central coordination, you
can verify normally and "anyone" can run a keyserver again. With all
the pros and cons that entails.

GnuPG can pretty much define what it wants here. Including changing the
URL scheme name if needed to avoid confusion. TLSA records are
available for opportunistic TLS. Effectively, "DANE for HKP with
work-arounds to handle the pool nature and bounce into a verifiable name
for arbitrary pool names". Shove a TLSA record in reverse DNS to
indicate it's supported and you're good. Hrm, probably don't strictly
need the reverse DNS to be DNSSEC-signed, as long as the
TLSA-or-other-marker is present and the forward DNS is still signed.

There's ways around it, but none of it will make folks who object to
DNSSEC happy. Tough.

-Phil

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Keyservers and GDPR [ In reply to ]
Hi,


On Mon, 2019-05-13 at 19:35 +0200, ilf wrote:
> So far, I stand by last year's statement:
>
> > tl;dr: Keep calm and keep running keyservers.
>
Are you standing by your statement because you believe that processing
that data is lawful or because you don't fear the consequences of a
potentially unlawful processing of data?

Cheers,
Tobi


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Keyservers and GDPR [ In reply to ]
Tobias Mueller:
>> So far, I stand by last year's statement:
>>> tl;dr: Keep calm and keep running keyservers.
> Are you standing by your statement because you believe that processing
> that data is lawful or because you don't fear the consequences of a
> potentially unlawful processing of data?

I stand by my statement because of the reasons I explained last year.
https://lists.gnupg.org/pipermail/gnupg-devel/2018-May/033708.html

--
ilf

If you upload your address book to "the cloud", I don't want to be in it.

1 2  View All