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.

In T5214#140791, @werner wrote:

For directories this can't be done because not only the server reads the directories but also other deployment tools (e.g. rsync).

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.

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.

thanks a lot dkg and werner :)

thanks!

Done; will go into 2.2.21 (T4897).

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.

Fixed for 2.2.19 and master

In T4726#130765, @werner wrote:

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).
[...]
To answer your question: With the exception of case two this is desired behaviour also in the future,

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.

In T4726#130609, @werner wrote:

-r  STRING

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.

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.

@werner, you seem to be saying that -r does not imply "key lookups on remote services". Is that correct?

In T4726#130341, @werner wrote:

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.

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?

Thank you @dkg for creating the bug report! I would like to glean the following information from the above mentioned discussion.

This was also raised for (hopefully) wider discussion on the IETF mailing list.

Done for master and 2.2.