Page MenuHome GnuPG
Create Task
Maniphest T3324

Activate Web Key Discovery by default
Closed, ResolvedPublic
Actions

Description

If gnupg is called with a mailbox and --locate-keys it will try via https or tor to find a key on the domain of the mailbox.
Similarly if auto-key-retrieve is active and a verification is called on a signature that contains the senders address or the --sender argument is provided a WKD lookup would also be done.

While this might be a slight "Web Bug" in that it may leak the information if someone searches for a key, this information leak is in my opinion smaller then the advantage that MUA's can use --locate-keys to automate key discovery.

Enigmail, GpgOL and KMail have support to use --locate-keys for key discovery and provide the sender argument on verification.

GnuPG should have it enabled by default so that these MUAs do not need to modify the gnupg configuration to benefit from Web Key Discovery.

I would like to see this in gnupg-2.2 and Gpg4win-3.0 and also don't want to mess with the defaults in Gpg4win.

Revisions and Commits

rG GnuPG
rG7e1fe791d188 gpg: Default to --auto-key-locate "local,wkd" and --auto-key-retrieve.

Event Timeline

• aheinecke created this task.Aug 2 2017, 11:34 AM
• werner raised the priority of this task from Normal to High.Aug 2 2017, 12:37 PM

So your suggestion is that

auto-key-retrieve
auto-key-locate local
auto-key-locate wkd
auto-key-locate dane

shall be the new default unless --disable-dirmngr is also used?

I am in favor of this. The user could disable this, but keeping dirmngr, by setting any of the two option in the config.
Shall we add DANE or leave it out in anticipation that WKD will be THE service? We could also hard code a blacklist of large mail providers from which we know that they won't support WKD.

• aheinecke added a comment.Aug 2 2017, 1:51 PM

Yes.

IMO for now we should not add DANE as this has been published for a while and we don't see widespread adoption. To avoid additional delays I would keep it disabled by default for now. But you know the pros / cons there better then me.

Hardcoding a list mh. I'm not a fan of that idea.

  1. Theoretically it might hinder new adopters *waves friendly at google*
  2. We would have a "central" blacklist that is cooked into code
  3. danger of bikeshedding discussions like why is Outlook.com on the list but not hotmail.com and can you please add yahoo.com

So if we do this I would make it configurable for the user / administrator so that we are not "controlling" the list and it might help with troubleshooting or maybe even a usecase like "I don't want to query .incrimnatingdomain.com but others" but such a user should imo disable auto-key-locate.

Just to clarify:
auto-key-locate clear
auto-key-locate nodefault

would also disable this, right?

• werner added a comment.Aug 3 2017, 7:54 PM

Yes, any auto-key-locate entry should disable the defaults.

I am fine with a blacklist for web key directory access implemented in dirmngr. I will give it a shot.

• werner added a commit: rG7e1fe791d188: gpg: Default to --auto-key-locate "local,wkd" and --auto-key-retrieve..Aug 4 2017, 10:14 PM
• werner added a comment.Aug 4 2017, 10:16 PM

auto-key-locate now defaults to "local,wkd" and --auto-key-retrieve is also the default.

• werner closed this task as Resolved.Aug 7 2017, 1:16 PM