Web Key Directory related
Mar 7 2021
Maybe have gpg-wks-client(or also --export-filter) print a warning if the filtered result has a key expiration different than the original key? That seems the simplest way tp approach the problem.
Feb 23 2021
Feb 11 2021
Jan 29 2021
See also https://gitlab.com/openpgp-wg/webkey-directory/-/issues/3 which is the same issue.
Jan 15 2021
This ambiguity appears to be the cause of a recent epic (and to me, largely incomprehensible) thread on gnupg-users. It would be great to have the WKD guidance about fallback strategy be much more explicit. Any room for ambiguity here leads to different outcomes from different WKD clients, and quite a bit of confused discussion by their users.
Dec 31 2020
Dec 30 2020
Dec 11 2020
The specs might just want to say that it just expects the wildcard to be broken, not that it expects an empty record.
Than put something into the TXT - it does not matter and is only used to break the wildcard.
Dec 10 2020
Cloudflare doesn't seem to allow empty DNS TXT records...
From the specs:
There's a wildcard CNAME, it's not _really_ configured. It's not a good assumption that a CNAME == configured and it doesn't have a reasonable fallback, IMHO.
If you configure the subdomain in the DNS this will be used. Thus get a cert for it. The old method should not be used and thus if the openpgpkey subdomain exists gpg concludes that the admin is aware of the new scheme.
Hm, I don't want to remove the CNAME just so that GPG WKD would work, is there a way to fix this? Is there a good reason why after "Advanced"/subdomain lookup it doesn't try "direct"?
Oh, it's using the openpgpkey subdomain because of the CNAME but that's not actually being served by the server.
Aug 7 2020
Apr 9 2020
thanks a lot dkg and werner :)
Mar 30 2020
Done; will go into 2.2.21 (T4897).
Mar 23 2020
Feb 5 2020
Jan 14 2020
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.