Page MenuHome GnuPG
Create Task
Maniphest T4595

GPG: auto-key-retrieve should prefer WKD over Keyserver
Closed, ResolvedPublic
Actions

Description

I think that I have reported this already but I can't find the issue anymore.

auto-key-retrieve first fetches from the keyserver and tries WKD only as a fallback.

That is bad because we can assert some trust based on the key origin if the key came from WKD. We cannot assert that trust if the key came from a keyserver.

So in GpgOL you would get "Level 2 trust" in a key if you received it through the "locate-key" mechanism but no trust if you received it by verifying a mail.

Having the key from WKD would also help with the auto update mechanism that is based on the key origin.

Details

Version
master

Revisions and Commits

rG GnuPG
rG3242837d203a gpg: With --auto-key-retrieve prefer WKD over keyservers.
rG96bf8f477805 gpg: With --auto-key-retrieve prefer WKD over keyservers.

Related Objects
Search...

Event Timeline

• aheinecke created this task.Jul 1 2019, 9:13 AM
ilf added a subscriber: ilf.Jul 1 2019, 12:02 PM
• werner added a parent task: T4606: Release GnuPG 2.2.17.Jul 3 2019, 6:11 PM
• werner edited projects, added gnupg (gpg22); removed gnupg.
• werner moved this task from Backlog to For next release on the gnupg (gpg22) board.Jul 3 2019, 6:14 PM
dkg added a subscriber: dkg.Jul 3 2019, 7:11 PM

auto-key-retrieve happens in the context of signature verification when the certificate is missing. If no signer User ID subpacket is present in the signature, then WKD simply won't work.

If a signer User ID is present, its value may or may not have anything to do with the visible sender of the message.

Assigning "trust"(‽ i think you don't mean the same thing as gpg means for "trust", please use a distinct term) based on the fact that it was fetched via WKD in the context of an arbitrary signature seems pretty risky. What is the user supposed to infer about this certificate, even if it allows validation of the signature?

wiktor-k added a comment.Jul 3 2019, 7:26 PM

@dkg I believe @aheinecke gave the GpgOL description just as an example of why WKD-first retrieval would be beneficial (for details of that see https://wiki.gnupg.org/AutomatedEncryption#Trust_Levels) and I believe this ticket is a follow-up to my question on gnupg-devel ML: https://lists.gnupg.org/pipermail/gnupg-devel/2019-June/034372.html

If you see problems with the trust levels in context of GpgOL I think a new, different ticket would be appropriate.

• werner added a commit: rG96bf8f477805: gpg: With --auto-key-retrieve prefer WKD over keyservers..Jul 5 2019, 10:33 AM
• werner added a commit: rG3242837d203a: gpg: With --auto-key-retrieve prefer WKD over keyservers..Jul 5 2019, 10:44 AM
• werner closed this task as Resolved.Jul 5 2019, 10:49 AM

Done for master and 2.2.

The order of methods tried to lookup the key is:

  1. If a preferred keyserver is specified in the signature and the option honor-key‐server-url is active (which is not the default), that keyserver is tried. Note that the creator of the signature uses the option --sig-keyserver-url to specify the preferred keyserver for data signatures.
  1. If the signature has the Signer's UID set (e.g. using --sender while creating the signature) a Web Key Directory (WKD) lookup is done. This is the default configuration but can be disabled by removing WKD from the auto-key-locate list or by using the option --disable-signer-uid.
  1. If the option honor-pka-record is active, the legacy PKA method is used.
  1. If any keyserver is configured and the Issuer Fingerprint is part of the signature (since GnuPG 2.1.16), the configured keyservers are tried.
• werner mentioned this in T4606: Release GnuPG 2.2.17.Jul 9 2019, 3:21 PM