Web Key Directory related
Tue, Jan 14
Thank you for resolving this issue! I am successfully using version 2.2.19 from the gnupg (2.2.19-1~bpo10+1) package of Debian Backports.
Dec 17 2019
Dec 4 2019
Fixed for 2.2.19 and master
Nov 23 2019
Nov 16 2019
Given that the the angle brackets are elsewhere used to indicate a search by mail address, it would be okay to allow for them in this case too (that is dkg's second example). The risk of a regression in that case is pretty low.
Nov 7 2019
does a remote key lookup only if STRING is a valid addr-spec. No extraction of the addr-spec from STRING is done and thus angle brackets inhibit the use of a remote lookup. This was implemented in this way to be as much as possible backward compatible.
Oct 28 2019
Oct 24 2019
@werner, you seem to be saying that -r does not imply "key lookups on remote services". Is that correct?
Oct 23 2019
This is a misunderstanding. The extraction of mail addresses is only doe for key lookups on remote services. Thus the -r case is as intended.
Is this task maybe related to T1927?
Sep 2 2019
Aug 21 2019
This was also raised for (hopefully) wider discussion on the IETF mailing list.
Aug 20 2019
Jul 5 2019
Done for master and 2.2.
Jul 4 2019
Fix will be in 2.2.17
Jul 3 2019
@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
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.
I did some manual tests using netcat and KS_FETCH to test the redirection.
I think you're suggesting accepting *any* path if the hostname of the proposed redirection matches openpgpkey.example.org when querying the WKD direct URL for an @example.org address. That would also be a fine solution from my point of view.
I head the same idea when I read your configuration. Given that the advanced lookup was not reallydeployed (see T4590) I also expect that we will receive complains now that it works. Thus white listing any "openpgpkey." seems to me a reasonable easy solution.
Will be in 2.2.17
Oh dear, that happens if one is always on master. I simply forgot to cherry pick the change from master back in November.
Two commits, though.
@werner, thanks for the pointer to the report, that's certainly useful. And i'm happy that organizations like SektionEins are doing GnuPG audits and publishing their results regardless of who paid for them.
See https://sektioneins.de/en/blog/18-11-23-gnupg-wkd.html for details. In short they fear that companies using IP based security for internal services can be attacked via redirect request and in particular becuase that can happen in the background without the user noticing. I am not concerned but we had long lasting discussions also with protonmail about this and the result was that we need to have this protection. We do not know who requested and paid for the audit from SektionEins and they won't tell us.
Jul 2 2019
We need to rewrite the Location to avoid a CSRF attack. See fa1b1eaa4241ff3f0634c8bdf8591cbc7c464144