As a counterpoint to my previous entry about key signing policies, I thought
it would be amusing to juxtapose a note that, yet again, using PGP/GPG in the real world
has become more difficult.
This time, it’s because one of the most popular ways of acquiring keys for
other people — the sks-keyservers.net pool of key servers — has hung up
its boots.
The site itself says that this was the result of “GDPR takedown requests”;
this appears to mean requests to remove personal information under
Article 17 of the GDPR, commonly known as the “right to be forgotten”.
Of course PGP/GPG public keys usually include the owner’s name and e-mail addresses
as part of the user IDs that are signed to make the web of trust work.
The way the SKS key server software works doesn’t allow removal of
a user’s key: it’s designed to propagate every key known to every node.
Manually removing a key from a node, even if that were possible, would be futile
as it would simply arrive again from another node (or could be uploaded again by
a third party).
If you’re looking for a replacement for the SKS key server pool, one option is
to find a key server that is still in operation, such as “old faithful” at
pgp.mit.edu which is unlikely to be swayed by requests
based on the EU-centric GDPR. Some other servers are based on
the more modern Hockeypuck software, although it’s not clear to me that
it’s any less prone to the same issue that did away with the SKS pool.
For the moment, I’m using pgp.re; we’ll see how it goes.
The other service that’s of interest here is keys.openpgp.org.
This has been gaining popularity for a while as these days it’s configured as the
default key server in a number of packages. It’s probably not going to run into the
GDPR issue by virtue of its requirement that if you upload your key there and
do nothing else, the user IDs on your key are not displayed on privacy grounds.
To make your user IDs visible, you must explicitly request a management link
to be sent to your e-mail address, then follow that and enable visibility for the
e-mail address on that key. You can also delete the e-mail address from the
key if you want.
Unfortunately, by far the majority (upwards of 90%) of the keys in
my public keyring are present in keys.openpgp.org but without any user IDs.
This makes them essentially useless unless you’ve previously exchanged a copy
of the key directly; gpg for example refuses to even import public keys that lack
a user ID:
$ gpg --recv 0xXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
gpg: key XXXXXXXXXXXXXXXX: new key but contains no user ID - skipped
gpg: Total number processed: 1
gpg: w/o user IDs: 1
If you find yourself in this bind, the only option seems to be to somehow figure
out who the owner is (which is hard given that the user ID is missing) and then
get the full public key from them directly (which makes the use of a key server
close to pointless) or get them to go through the management process to expose
their user ID. This can be particularly tricky to explain because, of course,
everything works fine for them as they have a copy of the full key in their
own keyring.
