[Sks-devel] 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/

[Vincent Breitmoser]

Sigh, I just now noticed that I wasn't actually subscribed to sks-devel anymore,
I thought I was. I humbly apologize for the noise, and will go read the
relevant threads now :)

- V

[Gabor Kiss]

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?

I did. I agree with you.

Post by Vincent Breitmoser
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.

Except his/her name and e-mail address is uploaded by someone else.
(With a fake key of course.)

Gabor

[Niels Dettenbach (Syndicat IT & Internet)]

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.

[Kristian Fiskerstrand]

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

[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

[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

[Andy Mueller-Maguhn]

Post by Patrick Brunschwig
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.

I don´t know what Mailvelope uses (as they seem to integrate everything
in their webfrontend), but adding a verification procedure when uploading
a key (through the email-address of the key) into the SKS keyservers
seems to me like long overdue, as it also would solve to an larger extend
the problem mentioned by Gabor with fake-keys uploaded in $other persons
name.

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
with the GDPR i can´t say, but this sounds like a good idea in any case.

best,
A.

[Volker Birk]

Post by Andy Mueller-Maguhn
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
with the GDPR i canÂŽt say, but this sounds like a good idea in any case.

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.

Yours,
VB.

[Andrew Gallagher]

Post by Volker Birk
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

[Mike]

I don't think "resilient" can be used any more in relation to sks-keyservers as they drop offline on and off and even one malicious individual could take the whole network down if motivated enough.

On Tue, 6 Nov 2018 18:34:49 +0000

Post by Andrew Gallagher

Post by Volker Birk
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
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Mike]

I don't think "resilient" can be used any more in relation to sks-keyservers as they drop offline on and off and even one malicious individual could take the whole network down if motivated enough.

On Tue, 6 Nov 2018 18:34:49 +0000

Post by Andrew Gallagher

Post by Volker Birk
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
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Andrew Gallagher]

Post by Mike
I don't think "resilient" can be used any more in relation to sks-keyservers as they drop offline on and off and even one malicious individual could take the whole network down if motivated enough.

Individual servers drop on and offline but the network as a whole is more robust. It is easy to take down the entire network of course, but this is very noisy. It is very hard to selectively prevent only a particular revocation from being served by the keyservers. Most other methods of distributing keys allow for selective blocking of one domain or even one address.

A

[holger krekel]

Post by Volker Birk

Post by Andy Mueller-Maguhn
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
with the GDPR i canÂŽt say, but this sounds like a good idea in any case.

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.

I happen to be similarly skeptical of key servers and don't want
to spend much effort with helping to evolve the concept.
I might be wrong, though, and there are good uses that solve real
security issues for people. When i say "real security issues"
i mean those who otherwise are oppressed and imprisoned for real,
not in some potentiality. It's about real outcomes for people
and not some security ideal.

Some folks certainly think key servers are useful and i respect them.
And also, who knows, i might be missing something. I admit that
so far the arguments pro key servers (eg revocation) have
not made me lean more towards going for it.

holger

[holger krekel]

Post by holger krekel

Post by Volker Birk

Post by Andy Mueller-Maguhn
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
with the GDPR i canÂŽt say, but this sounds like a good idea in any case.

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.

I happen to be similarly skeptical of key servers and don't want
to spend much effort with helping to evolve the concept.
I might be wrong, though, and there are good uses that solve real
security issues for people. When i say "real security issues"
i mean those who otherwise are oppressed and imprisoned for real,
not in some potentiality. It's about real outcomes for people
and not some security ideal.
Some folks certainly think key servers are useful and i respect them.
And also, who knows, i might be missing something. I admit that
so far the arguments pro key servers (eg revocation) have
not made me lean more towards going for it.

Just to be clear, i am refering to key server usage for e2e email.

For supporting Debian and similar other ecosystems key servers
have served quite well as far as i understand. And then, reconciling
key servers with the GDPR for public signing and verification
infrastructure seems like a good idea (including revocation i guess).

holger

[Werner Koch]

Post by Volker Birk
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

[Yegor Timoshenko]

Post by Werner Koch
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.

Storing signatures with issuing keys (instead of keys that are
being signed) should limit abuse potential while still allowing
for WoT.

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

World-writable storage is still a problem: even if no search is
present, at the very least means arbitrary writes. Proof of work
can both help limit this misuse vector.

Storing immutable data, distributed recon, proof of work, that
sounds like something a blockchain should do to me.

[Yegor Timoshenko]

Post by Werner Koch
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.

Storing and distributing signatures with issuing keys (instead of
keys that are being signed) should limit abuse potential while
still allowing for WoT.

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

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.

[Andrew Gallagher]

Post by Yegor Timoshenko
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]

Post by Andrew Gallagher

Post by Yegor Timoshenko
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
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]

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

[Yegor Timoshenko]

Post by Werner Koch
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.

It's not just storage, it's also immutable and distributed. It's
very different from P2P in that operators will have to host that
content less than voluntary, and it's different from mail account
in that it's public.

For how problematic that might be, see
https://fc18.ifca.ai/preproceedings/6.pdf.

[Andrew Gallagher]

Post by Yegor Timoshenko
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

[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

[Mike]

On Wed, 07 Nov 2018 20:52:35 +0100

Post by 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).

There are still the keyserver dumps which are accessable to anyone who wants them!

[Werner Koch]

Post by Andy Mueller-Maguhn
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

[Mike]

So it seems like the usual response is to ignore the fatal issues that could affect this network. 6 months on from the first set of PoC's and no one has stepped forward to fix them - they have only attempted to defend the network through pride. How is anyone meant to trust infrastructure run by people who avoid problems like this?

As usual, people keep burying their heads in the sand with nothing more than excuses. Something as simple and small as a Raspberry Pi could down the entire network. "Resilient against governments"? I don't think so! These servers no longer provide the function they once promised, and this needs to be addressed by the leading figures of the community with direct and clear responses, not excuses!

I believe that Kristian is the main spokesperson? He has never once stepped forward and commented on any of the issues.

Kind Regards

Yakamo

On Wed, 07 Nov 2018 10:13:06 +0100

Post by Werner Koch

Post by Andy Mueller-Maguhn
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
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

[holger krekel]

Hi Werner, all,

i'd appreciate if we can close this "GDPR and key servers" subject
and end sending mails about it to three mailing lists.
The Autocrypt ML subscribers are likely either also subscribed to
at least one of openpgp-email/gnupg-devel or mostly not
interested in further detailed discussions about key servers.
so let's at least leave out the Autocrypt ML.

thanks,
holger

Post by Werner Koch

Post by Andy Mueller-Maguhn
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
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
_______________________________________________
Autocrypt mailing list
List info: https://lists.mayfirst.org/mailman/listinfo/autocrypt
To Unsubscribe
Or visit: https://lists.mayfirst.org/mailman/options/autocrypt/holger%40merlinux.eu

[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