This problem does not seem to exist in GnuPG 2.3.6.

gpg tries to find the "best" key using get_best_pubkey_byname (https://dev.gnupg.org/source/gnupg/browse/master/g10/getkey.c$1507), but the applied rules are not clearly documented in one place.

I don't like it either but the browser vendors don't like SRV records.

I still think that redirecting to another catch-all domain is contrary to the original goal and weakens the security model. We need to see what we can do about this.

Thank you, works now on Windows with openpgpkey.sanka-gmbh.de

Independently of that, it seems that gpg4win doesn't work with at least one widely deployed webserver in its default configuration, specifically Caddy, so this fix is well appreciated.

I still think that redirecting to another catch-all domain is contrary to the original goal and weakens the security model. We need to see what we can do about this.

Oof. That hinges on the certificate, guess we'll need to renew the bunch of them. I reconfigured, might take a while for all pages but ciphers should now be:

The ECDHE_ECDSA suites are not yet implemented in ntbtls and thus we can't agree on a common cipher suite. Will be solved in the next Windows version.

In the above test, I was using
Windows: 2.3.4
Debian: 2.2.12

I captured some logs server-side, and I do see this error:

Are you using 2.3.4 also on Windows?

I have the same error when using wkd.keys.openpgp.org with a CNAME DNS entry. The error occurs with Windows 10, 11 and Server 2019 (only the most recent versions tested). With Debian it works fine.

Good idea. Thanks. Goes onto 2.3 and 2.2

@mieth sorry for the delay. meanwhile I adjusted the ciphersuite of the WKD gateway to include an AES-CBC suite. would be interested if it works now on the setup you tested before.

Did you make another request for locating keys via WKD after adding the debug flags? I'm asking because when I do this I get the following log:

2022-02-10 17:49:59 dirmngr[6780] listening on socket '/run/user/1000/gnupg/d.f3hdqcrmjwf98p87yqjmuctx/S.dirmngr'
2022-02-10 17:49:59 dirmngr[6781.0] permanently loaded certificates: 130
2022-02-10 17:49:59 dirmngr[6781.0]     runtime cached certificates: 0
2022-02-10 17:49:59 dirmngr[6781.0]            trusted certificates: 130 (130,0,0,0)
2022-02-10 17:49:59 dirmngr[6781.0] failed to open cache dir file '/tmp/tmp.8P2EakNghu/crls.d/DIR.txt': No such file or directory
2022-02-10 17:49:59 dirmngr[6781.0] creating directory '/tmp/tmp.8P2EakNghu/crls.d'
2022-02-10 17:49:59 dirmngr[6781.0] new cache dir file '/tmp/tmp.8P2EakNghu/crls.d/DIR.txt' created
2022-02-10 17:49:59 dirmngr[6781.6] handler for fd 6 started
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> # Home: /tmp/tmp.8P2EakNghu
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> # Config: /tmp/tmp.8P2EakNghu/dirmngr.conf
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> OK Dirmngr 2.3.5-beta17 at your service
2022-02-10 17:49:59 dirmngr[6781.6] connection from process 6779 (1000:100)
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 <- GETINFO version
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> D 2.3.5-beta17
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> OK
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 <- WKD_GET -- werner.koch@gnupg.com
2022-02-10 17:49:59 dirmngr[6781.6] DBG: dns: libdns initialized
2022-02-10 17:49:59 dirmngr[6781.6] DBG: dns: resolve_dns_name(openpgpkey.gnupg.com): No name
2022-02-10 17:49:59 dirmngr[6781.6] DBG: dns: getsrv(_openpgpkey._tcp.gnupg.com) -> 0 records
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> S SOURCE https://gnupg.com
2022-02-10 17:49:59 dirmngr[6781.6] number of system provided CAs: 390
2022-02-10 17:49:59 dirmngr[6781.6] DBG: Using TLS library: GNUTLS 3.7.3
2022-02-10 17:49:59 dirmngr[6781.6] DBG: http.c:connect_server: trying name='gnupg.com' port=443
2022-02-10 17:49:59 dirmngr[6781.6] DBG: dns: resolve_dns_name(gnupg.com): Success
2022-02-10 17:49:59 dirmngr[6781.6] DBG: http.c:1917:socket_new: object 0x00007f524c290e20 for fd 7 created
2022-02-10 17:50:00 dirmngr[6781.6] DBG: http.c:request:
2022-02-10 17:50:00 dirmngr[6781.6] DBG: >> GET /.well-known/openpgpkey/hu/waoubdep9643akkesx4xm3ynstfffiok?l=werner.koch HTTP/1.0\r\n
2022-02-10 17:50:00 dirmngr[6781.6] DBG: >> Host: gnupg.com\r\n
2022-02-10 17:50:00 dirmngr[6781.6] DBG: http.c:request-header:
2022-02-10 17:50:00 dirmngr[6781.6] DBG: >> \r\n
2022-02-10 17:50:00 dirmngr[6781.6] DBG: http.c:response:
2022-02-10 17:50:00 dirmngr[6781.6] DBG: >> HTTP/1.0 200 OK\r\n
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Date: Thu, 10 Feb 2022 16:49:59 GMT'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Server: Boa/0.94.14rc21'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Accept-Ranges: bytes'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Connection: close'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Content-Length: 957'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Last-Modified: Mon, 28 Jun 2021 17:47:11 GMT'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Content-Type: text/plain'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: ''
2022-02-10 17:50:00 dirmngr[6781.6] DBG: (957 bytes sent via D lines not shown)
2022-02-10 17:50:00 dirmngr[6781.6] DBG: chan_6 -> OK
2022-02-10 17:50:00 dirmngr[6781.6] DBG: chan_6 <- BYE
2022-02-10 17:50:00 dirmngr[6781.6] DBG: chan_6 -> OK closing connection
2022-02-10 17:50:00 dirmngr[6781.6] handler for fd 6 terminated

Add the following to dirmngr.conf:

debug ipc,dns,network,lookup

There are more debug flags but the above flags should cover anything related to the lookup.

You may have to restart the dirmngr to see the log-file option be honored. The gpg request to dirmngr should be visible in the log.

In T5813#154705, @bernhard wrote:

@mieth can you enable the dirmngr log and give it more message, you'll be able to diagnose the problem further. There have been problems in the past with the contents of the certificate store of Windows. It does not look like this is the problem you are facing, but the diagnostic messages should be helpful.

@mieth can you enable the dirmngr log and give it more message, you'll be able to diagnose the problem further. There have been problems in the past with the contents of the certificate store of Windows. It does not look like this is the problem you are facing, but the diagnostic messages should be helpful.

In T5813#154552, @Valodim wrote:

Might be an issue with matching ciphersuites? There was a problem with this before when GnuPG didn't support AES-GCM yet (https://dev.gnupg.org/T4597). That was added in 2020, maybe it's not rolled out far enough yet?

Either way, I hadn't considered this for the WKD relay. I'll look into enabling AES-CBC there, at least for backwards compatibility.

Might be an issue with matching ciphersuites? There was a problem with this before when GnuPG didn't support AES-GCM yet (https://dev.gnupg.org/T4597). That was added in 2020, maybe it's not rolled out far enough yet?

After further testing: The error does not occur if WKD is implemented directly under the respective domain.
The behavior of GnuPG differs between Windows and other platforms. However, it is not clear to me which version is behaving incorrectly. But it seems clear that there is no compatibility with the instructions at https://keys.openpgp.org/about/usage#wkd-as-a-service under Windows. (However this may concern another project.)

The server in the testcase is wkd.keys.openpgp.org which is referred with CNAME via the DNS. Referring to https://www.ssllabs.com/ssltest/analyze.html?d=wkd.keys.openpgp.org it shoud support TLS 1.2

Check that the server does not prohibit TLS 1.2 - a few server admins allow only TLS 1.3 for whatever security threats they have in mind.

Requires a new option or command.

@werner I think @Rombobeorn suggests something like

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.

See also https://gitlab.com/openpgp-wg/webkey-directory/-/issues/3 which is the same issue.

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.

Fix will be in 2.2.17

@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.

Thanks for the pointer, @werner. Certainly we want T4590 fixed.

We need to rewrite the Location to avoid a CSRF attack. See fa1b1eaa4241ff3f0634c8bdf8591cbc7c464144