WKD: returns only one pubkey (and why)

[Simon Josefsson]

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.

/Simon

Here are the SHA1 and SHA256 checksums:

52908bfc6e0bb6bbb54de4414e92c29fd13906d7  inetutils-2.4.tar.gz
dq7gwvCVRyhgDVEJVdaXpOwpMkMY54SEjbYG7jwJ42U  inetutils-2.4.tar.gz
df64dd4ea0e752a839dd51dd8a6a001c9c7d1e96  inetutils-2.4.tar.xz
F4nWsbGlff4qere1M+6fXf2cv1tZuxuzwmEu0I0PaLI  inetutils-2.4.tar.xz

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
keyring:

  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...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20230127/46536fcf/attachment.sig>