With the next gpg release (2.5.14) the keyboxd has an extended fingerprint table which carries a flags column. A bit in this column can eventually be used to mark subkeys with the "R" key flag and the search funtion can be enhanced to ignore keys with that flag set. This way we can more easily lookup the actual ADSK key (with the "E" key flag) and check whether this subkey has been revoked.

This is not a composite key specific thing despite that this is an extra challenge. The creation date is used to reconstruct a key if the public key has been lost and only the fingerprint is still available. A solution might be to test the all combinations of stored creation dates to match the fingerprint.

I can confirm that the patch fixes the issue. Thanks!

Alright, I change it from for notation data (and name).

[GNUPG:] NOTATION_NAME foo@foo.org
[GNUPG:] NOTATION_FLAGS 0 1
[GNUPG:] NOTATION_DATA bla%20bla%20��%20blub

with change:

[GNUPG:] NOTATION_NAME foo@foo.org
[GNUPG:] NOTATION_FLAGS 0 1
[GNUPG:] NOTATION_DATA bla%20bla%20%81%82%20blub

Since rfc2440 the PGP specs say:

That's a good question. Looking at https://datatracker.ietf.org/doc/draft-koch-librepgp/, it doesn't really specify what encoding is used for "human-readable" notation, so I'd personally lean towards encoding it to stay on the safe side. Unless I'm mistaken, status-fd will only be used locally, so escaping overhead should not be a problem.

The question is who shall correct the wrong encoding of notation data (assuming it is flagged as human readable). Escaping is a solution but needs a lot of extra bytes.

Especially when an LDAP is configured, keys should be automatically refreshed in short intervals (5 days? Configurable?) to notify users about revoked keys or signatures from a trusted key.
Keys that are close to their expiration dates should be prioritized.
Maybe users want to configure for what mail domains a lookup on a configured LDAP should be done.

@gniibe: Now that we use the KEM API, how do we proceed with this ticket?

Thanks for elaborating and the reference to rfc2440 - I now understand where that stray mail (between [RFC2822] and name-addr) in rfc4880 comes from...
Anyway, I'll treat it as if it says RFC 2822 mailbox and will treat angle brackets with bare addresses as optional.

I see, I had rfc2440 in mind which says:

By convention, it includes  an RFC 822 mail name, but there are no restrictions on its content.

thus 4880 refined it a bit. But in practice it is not the same because it is utf8 and not punycode or whatever. let's close this bug because they way it is used will work with all mail clients.

Thank you @werner ! I can confirm that the patches that have landed on STABLE-BRANCH-2-4 do clear up the DoS i was seeing for signature verification.

Also fixed for 2.4

This has been fixed in master with rG48978ccb4e:

Well, the different outcome depends on the order of the certificates or the string comparision in keyboxd. So it is not a keyboxd vs. pubring.kbx thing.

Closing this as duplicate of T7405. That ticket has the better task description as it was made after discussing offline how it could best be done.

For master fixed with rGbb6b38c24010258c7cb2da840d0a088fe43393b3 (Wrong bug id used).
Also fixed for gnupg24.

Pushed the fix for exporting OpenPGP v5 key: rG57dce1ee62c2: common,gpg,scd,sm: Fix for Curve25519 OID supporting new and old.

The OID is used for fingerprint computation, which complicates things.

Using the shorter OID for v5 is on purpose; thus we need to fix the export.