Web Key Directory related
Thu, Nov 7
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.
Mon, Oct 28
Thu, Oct 24
@werner, you seem to be saying that -r does not imply "key lookups on remote services". Is that correct?
Wed, Oct 23
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
Jul 1 2019
Jun 28 2019
I recognize that adding network activity to the test suite can be complicated (not all test suites are run with functional network access), but if it is possible to have a unit test or something (that doesn't do network access, but just looks at what the dirmngr *would* have tried somehow?), that would be great. Thanks for looking into this!
Confirmed; that looks like a regression.
Apr 1 2019
Mar 21 2019
Jan 25 2019
Dec 5 2018
Sounds good! I give it to me for testing / documenting this.
Dec 4 2018
With master we can now do: