“A nearly impenetrable thicket of geekitude…”

SKS Key Servers Gone

Posted on July 5, 2021 at 16:53

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