gpg --locate-key should refetch via wkd, if configured and no good pubkey found
Open, LowPublic

Description

Tested with gpg 2.2.12 and 2.2.20.
Setup:
There is a pubkey for recipient B@example.intevation.de in my local gpg, but it has been expired. The new or updated pubkey is available via WKD.

I want to automatically encrypt to B and use gpg --locate-key b@example.intevation.de
to get a good public key.

Result:
I don't get a good pubkey.
Expected result: I do get a good pubkey because one is fetched via WKD.

Considerations:
The default search has WKD in it, so people would expect it to work if no good key is found. There is some asymmetry when calling --locate-key that is works the first time and then later stops working. As gpg (via dirmngr) provides for the ability it makes sense to not have the using client do another command with different --auto-key-locate clear,nodefault,wkd or so to be sure. Because this would mean it would be done like this each time, thus leading to more WKD requests then if gpg just decides to only issue a request if necessary (or from time to time).

Not doing a WKD request by default would open an possible attack vector because once M manages to insert an expired pubkey into my store, the regular command does not work and thus may prevent me from sending an encrypted email to B.

bernhard created this task.Aug 18 2020, 4:10 PM
werner added a subscriber: werner.Aug 18 2020, 7:21 PM

If you use

gpg -er b@example.intevation.de

the expired key should be detected and replaced by a copy from the directory. A precondition here is that the key was initally fetched from the directory.

To force an update you can use --locate-external-key

Thinking about the logic from an email application viewpoint:
To display what will happen, I want to know if I can encrypt to an email address and what trust level I have in the public key I'll find.

  1. Trying to encrypt to find out about this, feels odd. So it would be to have a key-listing first, I guess.
  1. If the pubkey was not fetched by WKD, but I want it fetched in case I'll have to do this explicitely. Using --locate-external-keys (aka --locate-keys) with just WKD configured like above. And this will always do a request, even if I've just done it 2 hours ago and if there is a local pubkey that is fine (and updated).
  1. (Being curious, can I see somehow for a pubkey if it was fetched by WKD?)

Overall to me it makes more sense to have dirmngr/gpg do the logic of only asking if it is necessary in the default settings (--auto-key-locate local,wkd)

werner triaged this task as Low priority.Aug 19 2020, 1:06 PM
werner edited projects, added Feature Request, gnupg; removed Bug Report.

On the ml there was another request for this use case

Von: Dmitry Alexandrov <dag@gnui.org>

it would be nice, if GPG were not interpreting locating an expired key as success,
but continued with the next method instead:

https://lists.gnupg.org/pipermail/gnupg-users/2020-August/063934.html

if a user decided to use the Web Key Directory, this should be used instead of falling back to whatever has been configured (nothing else by default)

Note:

--locate-external-keys exists since 2.2.17 and ignores the local keys.

(I knew about the option, but thought it was the same as --locate-keys because in the manual they are listed directly below each other.)