Hey Werner,

I'll reopen this ticket here, since the underlying issue is not quite resolved yet as @dkg helpfully outlined above.

In that case, it's a bug in gnupg and there's nothing I can further do from my side 🤷

It seems we were still providing the expired DST certificate, which led to an additional yet invalid trust path, which gnupg didn't consider "valid" overall. Mainstream TLS implementations are more lenient here which masked the issue for a bit.

I suppose you're right, we might have crossed that bridge a while ago. Simple availability of certificate- or even signature-specific keyserver URIs just make the risks of honor-keyserver-url more obvious than before.

This is a reasonable feature, however it should be noted that this implies a fairly large metadata leak: You are essentially adding a URI to signatures that will be pinged on signature verification.

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.

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:

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

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

Gook luck on Solaris with this suggestion ;-)

For the record, the typical response to "it doesn't work" support requests for keys.o.o still comes down to killall dirmngr.

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?

The sks pool is now officially gone.

The last server of the HKPS pool dropped off for several hours yesterday, during which hkps.pool.sks-keyservers.net could not be resolved.

Perhaps of interest for this issue: the HKPS pool has consisted of only a single server for a couple of months now.

I'd be interested, is this is still on the agenda?

ftr, here is the thread I had in mind but couldn't recall above. @aheinecke is that your thinking, or a more pgp/mime bound mechanism as @dkg assumed?

Werner said that it's possible in OpenPGP to also put the pubkey into the signature. (...) The nice advantage is that this will also work for files.

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

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

that does look like your host can resolve domains for ipv6 addresses, but can't actually connect to them. what does host keys.openpgp.org say? And ip a?

but keys.openpgp.org resolves only to a v4 address.

That sounds like you might have a different issue in mind?

Sorry, I don't know which source code comment you are referring to. You mention the comment at https://dev.gnupg.org/T4628#128529 as well, but neither this commit nor be99eec2b105eb5f8e3759147ae351dcc40560ad contain such comment.

I'm confused by this commit: Third-party sigs were the ones used for flooding, and those are dropped with self-sigs-only. Is the additional clean operation still necessary for the mitigation? Wouldn't it be easier to just not set the import-clean flag in the first place for the default keyserver options?

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.

So, what about this? If I recall correctly, we had agreed in the call to merge this patch, at least into master?

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

We should put it of the agenda od the Brussesl summit in 3 weeks. I have a few ideas what we can do in gpg.

and from my understanding they are sending the self-signatures anyway.

Done. Hopefully this works now :)

Which is a bad idea because CBC is still a very common cipher mode.

It's been a while, any word on this? I sent the DCO as requested. Are there any technical concerns left to address?

A possible exception here is that .onion TLDs should stick with HKP by default

I disagree that it's conceptionally the same, unless you also consider any key on an HTTP server to be "conceptionally the same" as WKD.

Certain origins do have special treatment but in general the key origin is meta data for the frontend.

I'm a bit confused. The origin of Autocrypt keys is clearly different from keyservers ("ks"), why would they use the same value? I was aware that origin values are mapped to integers, but your description seems to imply that these integers have significant ordering in terms of trust. The documentation in the man page is a bit bare bones, but my interpretation of "key-origin" was that it simply stated the method of discovery for a key, leaving any implications of trust to the client. Is this incorrect?

Fair enough. Let's wait and see what others think.

The same *cannot* be said for a subkey that is marked specifically for certification or signing, and not for decryption.

I'm sorry but the explanation you give does not address the original issue I described, and which dkg then clarified. The discussion about AE is tangentially related, but the issue I described relates to the gpg interface:

Sorry, I don't understand. Can you describe your use case in more detail?

a key that is signed as its own subkey, in a construct where the key and subkey have the same fingerprint? what ever could be a valid use case for such a scenario?

uploaded the offending key for reference:

Well, I gues it's complex enough to warrant strategic discussion, which can be done in this ticket :)

Hm. Could you elaborate on that? Why do you think it's dangerous?

Isn't it much nicer if we semantically convey that a key doesn't have associated user id information, compared to just listing such keys between "Andre" and "Arnold"? I'd much rather special case the empty string in the key list than an arbitrary string that may or may not have a universally obvious meaning.

I think "anonymous" user ids are a valid use case, since openpgp doesn't allow "no" user ids. Disallowing zero-length user ids will just cause implementations that intend to use anonymous user ids to use another type of "empty", like a single space character. And the effect of that will be that it's no longer trivially defined what an "anonymous" user id is for special handling, e.g. showing a localized "anonymous key" placeholder. Please don't restrict zero-length user ids.

Well, yes, it's not general authentication like AE provides, didn't think this through entirely. However, handing encrypted data to gnupg and then not being sure if it was actually decrypted with a passphrase makes even the confidentiality property questionable.

seems this was fixed along the way, then. I only tested with 2.1.18.

here's a public key version of the same key. it was available easier and should reproduce the bug just as well

user ids with length 0 do conform with rfc4880, though

The key was created programmatically by my standard approach, which is bastardizing openkeychain unit tests. good question about the passphrase - I don't remember exactly, but I'm guessing it's either empty or "x". doesn't really matter in the context of this particular bug I guess :)

-----BEGIN PGP PRIVATE KEY BLOCK-----