Just reading this issue in detail.

Pushed fix to master and STABLE-BRANCH-2-2.

Thanks for your log.

$ cat /run/user/1000/dirmngr.log

2020-07-11 19:33:44 dirmngr[2305.0] permanently loaded certificates: 140
2020-07-11 19:33:44 dirmngr[2305.0]     runtime cached certificates: 0
2020-07-11 19:33:44 dirmngr[2305.0]            trusted certificates: 140 (139,0,0,1)
2020-07-11 19:39:24 dirmngr[2305.6] force-crl-refresh active for issuer id CE04B58CBA5B8069AA0D503634B861593BE86F20; update required
2020-07-11 19:39:24 dirmngr[2305.6] number of system provided CAs: 148
2020-07-11 19:39:24 dirmngr[2305.6] error creating socket: Address family not supported by protocol
2020-07-11 19:39:24 dirmngr[2305.6] error connecting to 'http://cdp1.pca.dfn.de/global-root-g2-ca/pub/crl/cacrl.crl': Address family not supported by protocol
2020-07-11 19:39:24 dirmngr[2305.6] error retrieving 'http://cdp1.pca.dfn.de/global-root-g2-ca/pub/crl/cacrl.crl': Address family not supported by protocol
2020-07-11 19:39:24 dirmngr[2305.6] crl_fetch via DP failed: Address family not supported by protocol
2020-07-11 19:39:24 dirmngr[2305.6] command 'ISVALID' failed: Address family not supported by protocol
2020-07-11 19:39:24 dirmngr[2305.6] force-crl-refresh active for issuer id 3476EB7C1E02B3BAF954EEE2EFD321F7B8E49D18; update required
2020-07-11 19:39:24 dirmngr[2305.6] error creating socket: Address family not supported by protocol
2020-07-11 19:39:24 dirmngr[2305.6] error connecting to 'http://pki0336.telesec.de/rl/TeleSec_GlobalRoot_Class_2.crl': Address family not supported by protocol
2020-07-11 19:39:24 dirmngr[2305.6] error retrieving 'http://pki0336.telesec.de/rl/TeleSec_GlobalRoot_Class_2.crl': Address family not supported by protocol
2020-07-11 19:39:24 dirmngr[2305.6] crl_fetch via DP failed: Address family not supported by protocol
2020-07-11 19:39:24 dirmngr[2305.6] command 'ISVALID' failed: Address family not supported by protocol
2020-07-11 19:39:24 dirmngr[2305.6] force-crl-refresh active for issuer id 70F42DB9235EC84DC35D445B3407CABF4324291C; update required
2020-07-11 19:39:24 dirmngr[2305.6] error creating socket: Address family not supported by protocol

@gniibe I saw that you didn't understand what I meant by "dirmngr stops working properly" in E663.
Have a look at this post in Archlinux forum.

Fixed; In master the code already uses our generic scheme parser.

DANE for OpenPGP is an experimental RFC (RFC-7929) and it is likely that we will remove the support because it is too hard for most users to add keys to a zone. Further a validating resolver on the desktop is too hard to maintain and the cause of too many other failures. And no, unbound etc is not an option because it is not usable by the majority of GnuPG users.

The same concern has been reported at https://bugs.debian.org/964033 -- if dirmngr is not going to follow the specification, it should at least document (and maybe warn?) about how it is divergent.

When I test it on Debian, disabling by,

Please get log of dirmngr, by putting

log-file /run/user/<YOURNUMBER-LIKE-1000>/dirmngr.log

Can you characterize the failure when ipv6.disable=1 ? The straightforward failure (connect() fails with EHOSTUNREACH after a few seconds) should presumably be treated the same as if some other host happened to be offline. That should result in dirmngr failing over to the next available address for the configured keyserver, right?

The problem is that I have not yet found a _portable_ way to detect proper working v6 or v4 networking without doing a test connection. For privacy reasons we don't want to do that.

Fixed in master and applied to 2.2 branch too.

We do this now always if --auto-issuer-key-retrieve is set. Also backported to 2.2

Data (ie.e CMS) signatures do now also work.

I'm honestly surprised this isn't being given any sort of priority.
gnupg for windows is simply broken. Even Kleopatra, its supplied and designated key management application doesn't work re: keyserver communication.

Okay certificate and CRL checking does now work with rsaPSS. Need to work on data signatures and check the compliance modes.

I started to work on it so that I can actually use the certificates on my new D-Trust card. This will be a verify-only implementation.

I'm using enigmail 1.9.9 because I'm on a mail client that doesn't use WebExtensions, so it's using gnupg for keyserver stuff. In this case that means I've been able to verify it's a gnupg issue (both Kleopatra and enigmail displaying the same issue as CLI).

@Moonchild wrote:

using enigmail with the new version

Just registered to report pretty much the same.
I've been using gpg 2 for a long while and it's been doing just fine, up to the point where people started using keys it didn't recognise that require a later version.

It is actually questionable whether PSS is a better padding scheme than PKCS#1, see
https://www.metzdowd.com/pipermail/cryptography/2019-November/035449.html . PSS seems indeed be rarely used; quoting Peter from a followup on his writeup: “If I get time over the weekend, and I can find a CMS message signed with RSA-PSS, I'll create a forgery using xor256.”

To summarize: The DGN CRL uses a the RSA-PSS Padding / Signature Scheme. ( https://de.wikipedia.org/wiki/Probabilistic_Signature_Scheme )

In T4513#132777, @Valodim wrote:

But searching on Keyservers is also in my opinion not a common use case for Kleopatra users.

Thanks for engaging constructively.

In T4513#132770, @aheinecke wrote:

Werner could you maybe at least check for an internet connection, I don't know how to do it on Linux but on Windows it's easy because windows has API for that.

But searching on Keyservers is also in my opinion not a common use case for Kleopatra users.

and by that bypassing all key source tracking as done by gpg. In any case searching by name or mail address on a keyserver should not be done - at least not by a GUI tool as used by non experienced users.

I agree that this is a tricky problem, but it should really be improved.

The problem is not to check whether there is a connection but on how to decide whether something is a pool or an explictly added single keyserver and how often should we try to connect or read from it. Without marking hosts as dead the auto search features won't work well.

@Valodim probably not so much as dirmngr might behave differently and not mark hosts as dead.

The proper solution is of course to use pkill instead of killall. SCNR.

I can attest to the "growing bit of popular lore": Roughly half the support requests I get to support@keys.openpgp.org boil down to an exchange of "it just doesn't work with a 'general error' message" -> "try killall dirmngr" -> "that did it". I have heard similar stories from @patrick from Enigmail users, and more than once heard people applying poweruser trickery like "I just have killall dirmngr in my resume.d".

The LDAP code is actually in very bad shape because @neal added it without utilizing the ldap wrapper and thus a timeout won't work reliable.

Unusable v6 interfaces are now detected on Windows and then not used.

The manual states that --standard-resolver is mostly for debugging. The reason you get an "not enabled" is that we can't allow direct DNS queries in Tor mode which would happen with the system (standard) DNS resolver.

See also D475.

Ping.

There is a growing bit of popular lore in the GnuPG community that "when keyserver operations fail, you solve that problem with killall dirmngr." I believe this suggestion is potentially damaging (the long-running daemon may be in the middle of operations for a client that you don't know about), but i suspect it is circulating as advice because it resolves the situation outlined in this ticket. For whatever ephemeral reason, dirmngr gets stuck, and fails to notice that this situation has resolved itself.

GnuPG ships a non-PKI certificate, specifically to authenticate hkps.pool.sks-keyservers.net. Now due to an implementation detail, this has been shown to potentially lead to authentication of other domains by this certificate, if a maintainer changes the default keyserver via the DIRMNGR_DEFAULT_KEYSERVER variable in configure.ac. Now arguably, this variable isn't exposed via ./configure, so it's not "officially" configurable - but evidently maintainers do want to change it. A trivial one-line patch was supplied to change the unintended and potentially security-problematic behavior into the (I believe) obviously intended one.

$ gpg-connect-agent --dirmngr 'getinfo version' /bye
D 2.2.17
OK

Can you check which dirmngr version you are running

gpg-connect-agent --dirmngr 'getinfo version' /bye

thanks for the dns explanation - IMHO, there should be added something about that in the wiki
When it does not work for you on http1 either, then I guess, it's really just some outdatedness of my gpg/dirmngr and this ticket can be closed.

It does not work either. Your problem is the use of a wildcard DNS for archlinux32.org:

The test above was with gpg master but I got the same result with current 2.2:

ok, I disabled it again. btw: why do we need openpgpkey.archlinux32.org in the cert? Is this standard or did I misconfigure something?

Thanks. Here is a dirmngr log:

I set archlinux32.org back to http2 - so you can see for yourself, how gpg fails to retrieve the key for buildmaster@archlinux32.org

I believe, it means, that it may fall back to http1.1 - the documentation is not clear to me on this.
A simple test however shows, that at least curl has no problems to use http1.1 or http1.0 with the http2 enabled nginx.

Does your ngix configuration mean that there is no fallback to standard http?

In T2300#90092, @aheinecke wrote:

Ah nevermind. I think myself that this is nobug and current behavior is correct.

To implement / test the "not literally RFC compliant but in practice better" behavior let us call this now a wish and feature request as there are certificates in the wild other then intevation's and customers in large institutions run into that.

Will be in 2.2.18

WKD and DANE/OPENPGPKEY offer rather distinct properties. I'd be hard-pressed to say that one is "better" than the other without understanding the threat model and concerns of the evaluator:

DNSSEC is a centralized CA system. Just different than the TLS one. Given that Certificate Transparency exists I'd say DNSSEC is less transparent than TLS. For example if you happen to have a .ly domain then the Libyan can silently control your signed zone. Given that there is no CT for DNSSEC they can do so selectively, for any connection they want. It wouldn't be the first problem with them.

In T4618#128103, @wiktor-k wrote:

I'm left wondering: are there cases where OPENPGPKEY would be preferred over WKD?

Just a note that we're now shipping this patch in debian unstable. It would be great if it was merged upstream.

I see. I am also mostly testing with ntbtls so I was wondering about the report. Thanks for reporting and fixing.

While I understand incorrectness, the risk in practice is not that high. So, I put this as "normal" priority.

Pushed the change to master as well as 2.2 branch.

Is this really necessary to duplicate functionality that already is provided by Web Key Directory?

With NTBTLS, it seems it works correctly.

I agree, many currently-shipped DNS client library implementations do not provide DNSSEC validity checks.

Sure it is not validated. Standard clients do not provide the system features to do that. That is one of the problems with DNSSEC adoption - it works only for servers in practice.

Ah, that makes sense, good catch. Seems this is just an issue of documentation, then.

And of course, thanks for your fix.

Applied to both branches. I have run no tests myself, though.

Fix will be in 2.2.17

I tried to implement this but this is troublesome for other programs using the interface because a common patter is to use --search-keys to get a listing and then use --recv-key to import the keys - That won't work and will require changes to --recv-key too. Thus this change will not go into 2.2. Anyway, it is not dangerous to have --search-keys because the new default for import from keyservers will be to strip all key-signatures.

I asked you to carry this to a mailing list and not re-open this task.