Implemented and backported for VSD 3.4

The "ca" root cert is not on the ldap, if that matters

In T8048#211860, @ikloecker wrote:

some other certificates, but I guess those are from other tests

It also happens on CLI:

With Gpg4win 5.0.0 the LISTKEYS after the server lookup lists the (ephemeral?) ca@gnupg.test certificate and (!) the bob@gnupg.test certificate (and some other certificates, but I guess those are from other tests).

1. VSD 3.3.4

1. Gpg4win 5.0.0

• gpg4win 5.0.0 @ win11

gpgme logs (also of vsd-3.3.4) will be useful.

I have not checked but I guess that the certificate is marked as ephemeal and kleopatra either lists ephemeral certificates or the ephemeral flag got removed to to a validation process,

Note: This does not happen on vsd-3.3.4

The gpgme logs show that the information for revoked keys should be there. We just need to check for it (and somehow visualize it).

pub:o:3072:1:3DA05D6B0A5998AF:1768822823:1863514800::::::::
fpr:::::::::C70F6D8F32DFE96F5C47C40B3DA05D6B0A5998AF:
uid:o::::::::search (valid) <search@gnupg.test>\r:

gpgme.log (vsd 3.3.4):

Another possibility would be to just add a revoked column (expiration date is already shown) to keep closer to the ldap schema.

The behaviour might have changed a bit because of the ldap: prefix i use now, or i have missed this case the last time:
Given some cert on the "download" server, I can find it, if dirmngr.conf contains only the "download" server, or if the "download" server is listed first:

Independent of keyserver order in dirmngr.conf, --search-keys still offers keys from the upload server, but the download fails:

For "Although the upload server is used for upload, the gpg message still displays the first keyserver" see T8025

Looks good to me on gpg4win-5.0.0-beta479 @ win11.

@timegrid I would not tag this ticket with LDAP, as it is not LDAP specific

State in Gpg4win-5.0.0-beta446 and vsd 3.3.4 is this:

setting this to resolved, werner already tested this

Tested on gpg4win-5.0.0-beta413 @ win11 with the following entries in dirmngr.conf:

Implemented but not tested at all.

The advantage of using a fingerprint for referencing a key is that there won't be any collisions in the keyid. Further this unifies the schema with an LDS (Windows) installation where DNs must anyway be unique. But take care the client needs to support this new flag. This will be the case for gnupg >= 2.5.12 (cf. T7756)