From 04451ff34bf38610758d40ecbc9b9040251876ab Mon Sep 17 00:00:00 2001 From: David Runge Date: Sat, 30 Apr 2022 23:02:48 +0200 Subject: Add article about new PGP key and WKD setup posts/2022/new-pgp-key-id-1793dad5d803a8ffd7451697bb992f9864fad168.rst: Add article about new PGP key `1793dad5d803a8ffd7451697bb992f9864fad168` and WKD setup using sequoia-pgp tooling. --- ...id-1793dad5d803a8ffd7451697bb992f9864fad168.rst | 182 +++++++++++++++++++++ 1 file changed, 182 insertions(+) create mode 100644 posts/2022/new-pgp-key-id-1793dad5d803a8ffd7451697bb992f9864fad168.rst diff --git a/posts/2022/new-pgp-key-id-1793dad5d803a8ffd7451697bb992f9864fad168.rst b/posts/2022/new-pgp-key-id-1793dad5d803a8ffd7451697bb992f9864fad168.rst new file mode 100644 index 0000000..15ce8fb --- /dev/null +++ b/posts/2022/new-pgp-key-id-1793dad5d803a8ffd7451697bb992f9864fad168.rst @@ -0,0 +1,182 @@ +.. title: New PGP key ID 1793DAD5D803A8FFD7451697BB992F9864FAD168 +.. slug: new-pgp-key-id-1793dad5d803a8ffd7451697bb992f9864fad168 +.. date: 2022-04-30 10:35:57 UTC+02:00 +.. tags: chain of trust, gnupg, gpg, infrastructure, openpgp, sequoia, sq, web key directory, web of trust +.. category: admin +.. link: +.. description: +.. type: text + +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. + +.. TEASER_END + +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: + +.. code:: sh + + gpg --locate-keys dave@sleepmap.de + +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: + +.. code:: sh + + sq wkd get dave@sleepmap.de + +The certificates can be inspected directly using |sq inspect|: + +.. code:: sh + + sq inspect --certifications <(sq wkd get dave@sleepmap.de) + +Additionally, the certificates can be imported into an existing |gnupg| based +keyring: + +.. code:: sh + + gpg --import <(sq wkd get dave@sleepmap.de) + + +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 +`_. + +.. |PGP| raw:: html + + PGP + +.. |chain of trust| raw:: html + + chain of trust + +.. |web of trust| raw:: html + + web of trust + +.. |WKD| raw:: html + + WKD + +.. |gnupg| raw:: html + + gnupg + +.. |sequoia-pgp| raw:: html + + sequoia-pgp + +.. |sq| raw:: html + + sq + +.. |key servers| raw:: html + + key servers + +.. |SKS| raw:: html + + SKS + +.. |hockeypuck| raw:: html + + hockeypuck + +.. |draft-koch-openpgp-webkey-service-11| raw:: html + + draft-koch-openpgp-webkey-service-11 + +.. |gpg| raw:: html + + gpg + +.. |wkd| raw:: html + + wkd + +.. |sq keyring join| raw:: html + + sq keyring join + +.. |sq wkd generate| raw:: html + + sq wkd generate + +.. |rsync| raw:: html + + rsync + +.. |WKDHosting| raw:: html + + WKDHosting + +.. |sq wkd get| raw:: html + + sq wkd get + +.. |sq inspect| raw:: html + + sq inspect -- cgit v1.2.3