SKS Key Servers Gone
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
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
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.