[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shutdown of and

From: Andrew Gallagher
Subject: Re: shutdown of and
Date: Wed, 23 Jun 2021 11:33:18 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0

On 23/06/2021 10:36, Gabor Kiss wrote:
On Wed, 23 Jun 2021, Andrew Gallagher wrote:

Actually (or its successor) is just a web page that
shows statistics about key servers. That should not public at all
so it would not attract any GDPR complaints.

In the context of this thread, we were clearly talking about the hkp(s) interface to the pool, not the statistics page.

The GDPR problem is with SKS itself. That is a nightmare in this era.

It's a problem at multiple levels, because even with GDPR-compliant software, a pool is problematic - because the pool's manager has little control over individual operators or their data retention policies, so is unable to guarantee deletion of personal data.

Even more I think it should keep the strong set only.

This would be a gatekeeping exercise, and hostile to new users. For example, I've been using PGP for over twenty years but it was only six or seven years ago that I got my key into the strong set.

There are several actions that other keystore codebases have taken to limit abuse, and which synchronising keyservers (i.e. Hockeypuck) should now consider:

1. Whitelisting packet types (Hagrid). There is no justification for keyservers to store UAT packets. Public keyservers should only store private key material, plaintext UIDs, sigs and attestations (see below). Fixing this will remove at a stroke the most terrifying abuse scenarios. (There are concerns with plaintext UIDs also, but these are less urgent)

2. Email verification (Hagrid, WKS). How to make this compatible with synchronisation is an open question. Keyserver operators could sign verified UIDs, but this would require all operators to explicitly trust each other.

3. Signature attestation (Hagrid TBC?). This requires an update to the OpenPGP standard, and quite a bit of client-side UX work, but is the definitive way to tackle third-party-sig spam. See Wiktor's earlier email.

There are also issues of managing dataset divergence, which will most likely require a refactoring of the storage back end and a new sync protocol, but this is a longer-term concern. For now we can use flag days and accept loss of backwards compatibility.

Andrew Gallagher

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]