WKD: returns only one pubkey (and why)

Wiktor Kwapisiewicz wiktor at metacode.biz
Fri Jan 27 09:40:02 CET 2023

Hi Simon,

On 27.01.2023 09:13, Simon Josefsson via Gnupg-devel wrote:
> 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.

I don't know if you know but if the signature contains Signer's User ID 
packet (added with --sender email at example.com option during gpg --sign) 
then when verifying you can use --auto-key-retrieve and it will use WKD 
to fetch the key (of course the Signer User ID packet is needed to 
supply the e-mail at verification time).

This makes verification one command instead of two (first get the key 
then verify).

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

There is keys.openpgp.org and it allows fetching keys via subkey 

Still, since it's technically possible to put multiple keys on WKD IMO 
the spec should say what to do when there are multiple keys there (e.g. 
prefer the most recent key, and specify what does it mean for key to be 

The problem, as described earlier, is only for encryption subkeys and I 
wouldn't mind if the e-mail client just used all valid available keys 
(for key rotation) but I think the notion of "one recipient, one key" is 
ingrained so hard that it's not going to change.

Kind regards,

PS. Sample clearsigned file with the Signer's User ID packet (remove #, 
you can pipe it to gpg --list-packets):

Hash: SHA256



More information about the Gnupg-devel mailing list