New PGP key ID 1793DAD5D803A8FFD7451697BB992F9864FAD168
As my current PGP key 91BD8815FE0040FA7FF5D68754C28F4FF5A1A949 will be
expired soon, I have created a new one to replace it.
You can get my new key 1793DAD5D803A8FFD7451697BB992F9864FAD168 as well as
the old one and the cross-signatures required to establish the chain of trust
between the two via Web Key Directory (WKD) (which should be used
automatically by gpg >= 2.1.23).
To not deal with the rather convoluted gnupg tooling I have created a deployment method for this using sequoia-pgp's sq, about which you can read in the rest of this article.
Key servers
Historically, there has been a set of key servers, which have been used to distribute the public keys of users centrally and/ or in a synchronized fashion. These key servers have been widely relied upon, but they suffer(ed) from a lot of issues in regards to privacy, stability and speed. Most notably the Synchronized Key Server (SKS) system collapsed under its technical debt and had to be shut down.
To this day there are still other large, non-synchronized keyserver systems around (e.g. hockeypuck, which drives https://keyserver.ubuntu.com), but they all suffer from the fact, that a large centralized setup, in which keys are only ever appended, does not scale.
Additionally, not all keyserver systems support all key types or signatures on keys, which is problematic, as they can not reflect upon chain of trust between two or more keys. This is very problematic for the web of trust of PGP.
Web Key Directory
At the time of writing the WKD system is formalized in draft-koch-openpgp-webkey-service-11. It describes a decentralized way of providing public key material via a given domain's webserver, by exposing specially crafted files.
WKD Deployment
Personally, I believe that the gpg commandline interface is incredibly convoluted and very complex. I therefore used sequoia-pgp's sq instead to combine PGP public key material and prepare the required directory structure.
In my personal wkd project I assembled a simple system consisting of easy to prepare directories in which to place PGP public keys, which are converted to a keyring using sq keyring join, converted into a WKD structure using sq wkd generate and synchronized using rsync.
As I do not provide an openpgpkey subdomain, I am using a direct domain
directory structure (see WKDHosting for further details).
Using keys from WKD
In theory all that is required for gpg to make use of WKD is a version
>=2.1.23. However, its use can be somewhat confusing:
The above only returns the new key
1793DAD5D803A8FFD7451697BB992F9864FAD168, but not the old
91BD8815FE0040FA7FF5D68754C28F4FF5A1A949. It is entirely opaque to the user
as to why.
Meanwhile with sq wkd get it is possible to return the public key material of both keys:
The certificates can be inspected directly using sq inspect:
Additionally, the certificates can be imported into an existing gnupg based keyring:
Using WKD, the need for providing a separate PGP public key file in the context of this website has been made obsolete and I have therefore instead replaced it with plain mentions of the PGP key IDs on the about page.