WKD: returns only one pubkey (and why)
simon at josefsson.org
Fri Jan 27 09:13:15 CET 2023
Simon Josefsson via Gnupg-devel <gnupg-devel at gnupg.org> writes:
> I think we can separate the use-cases even further like this:
> 1) Use WKD to map ONE email address to ONE public key to use for
> sending email to that address (i.e., encrypt).
> 2) Use WKD to find ALL public keys for an email address for verifying
> emails from that address (i.e., verify).
Let me modify that again, since my main use-cases really isn't e-mail
(where you have the Key ID to search for) but verifying signatures on
free software release tarballs, and using the e-mail adress of the
publisher as the search field, hence I see these use-cases:
1) Use WKD to map ONE email address to ONE public key to use for
sending email to that address (i.e., encrypt).
2) Use WKD to find ALL public keys for an email address for verifying
signatures signed by keys owned by that address (i.e., verify).
To expand even more to get feedback and suggestions on improving this:
my goal is to come up with the best/safest text to write in a software
release on how to verify OpenPGP signatures for the tarball.
Currently I'm using the text below, which recommends 'gpg
--locate-external-key' as the preferred mechanism and normally that uses
WKD and will try to refresh the key from the server (otherwise people
get old cached keys from local key storage). I like the simplicity and
UX of this approach. This mechanism must be able to retrieve all
currently valid keys for a particular e-mail address, otherwise people
will complain not finding the right key.
Second to using the e-mail, maybe retrieving by key id should be
preferred because that is more stable. However there aren't really any
stable working keyid-based OpenPGP key search engines left, are there?
So this method is not reliable. There also were issues with it using
only the first 64-bit of the key id, and I'm not sure this is fixed
(hence the text below uses only that to not give false sense of
security). The --recv-keys parameter behaves different for different
GnuPG versions wrt default keyserver and has been somewhat unreliable in
the last 5 years or so. It also requires additional configuration, most
GnuPG installation doesn't come with a default keyserver URL.
Downloading the key from a given https URL is safe. This is likely to
be the most reliable method right now, but it feels unsatisfying to me.
Here are the SHA1 and SHA256 checksums:
The SHA256 checksum is base64 encoded, instead of the
hexadecimal encoding that most checksum tools default to.
Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig file
and the corresponding tarball. Then, run a command like this:
gpg --verify inetutils-2.4.tar.gz.sig
The signature should match the fingerprint of the following key:
pub ed25519 2019-03-20 [SC]
B1D2 BD13 75BE CB78 4CF4 F8C4 D73C F638 C53C 06BE
uid Simon Josefsson <simon at josefsson.org>
If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.
gpg --locate-external-key simon at josefsson.org
gpg --recv-keys 51722B08FE4745A2
wget -q -O- 'https://savannah.gnu.org/project/release-gpgkeys.php?group=inetutils&download=1' | gpg --import -
As a last resort to find the key, you can try the official GNU
wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
gpg --keyring gnu-keyring.gpg --verify inetutils-2.4.tar.gz.sig
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 255 bytes
Desc: not available
More information about the Gnupg-devel