I used the GPGME function gpgme_op_assuan_transact_ext with an query string like this:

ad_query --subst --attr=dn,userAccountControl (&(objectcategory=person)(objectclass=user) (|(userPrincipalName={{email}}) (mail={{email}})))

Of course {{email}} must be replaced with the mail address queried, this might probably also be the login name.

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.

I created a Go test program that runs several Go routines, each of which verifies a byte array loaded from a file in advance. Each go-routine is spawned with a configurable delay in milliseconds. I tested it with 100 iterations, which resulted in at least 50 parallel processes. Each verification process uses its own context, as Crio does. I didn't encounter any errors.

Here is my repository with a README containing more information: https://git.sr.ht/~kulbartsch/gpgmego-verify-load-test

I made a comment on github.

Test with KF6 (open, close, open config dialog).

see T7098

Outlook problem that can't be fixed.
Workaround possible (First start message, then add recipients).

Fixed in most cases.
Edge cases will be examined further.

Discussion and background for naming things and german translation

Is not a GpgOL bug.
Full functionality will be possible with GpgOL/WEB.

When opening the notepad in Kleopatra, open it in a new (non modal) window.
This has the advantage that you can to open several notepads.
Kleopatra has currently only two views for the main window: "Certificates" and "Notepad". Using a separate window for the notepad removes necessity for the the "Certificate" button in the icon bar, as well as the corresponding entry in the "View" menu.
That would also make Kleopatra more homogeneous and cleaner.

Regarding the suggest list I would change the following:

There is another customer request for this too.

Yes, automatic scanning of the clipboard is not good. I withdraw the idea.

Some questions (wishes):

• Will the upload also be done to an configured LDAP Server?
• Can the upload-checkbox setting be configure via the Windows registry?

I suggest always updating modifications which are "exportable".

Last time I used the Non-Sucking Service Manager to create a windows service.
This works fine when the program gracefully stops on a OS terminate signal.
But this is an additional dependency.

I like the idea, but others might not.
Maybe the behavior could be made configurable?

That's the way it works today in some organizations:
If users can't delete their key they are requested to ask their GnuPG admin, they actually do so and the admin does help.

Experiences from customers are that people create their certificate, upload it to a server. Then they notice a mistake in their name and delete the whole cert and upload the new one. Now there are two certificates on the server. This is only one example of what can go wrong. Admins want this not to happen and that's the reason for this feature. More warnings will probably not solve the problem.

If you want to use gpgpass without a secret key, the most I would offer, if at all, is the option to use a symmetric key instead.
Maybe like this:

What's the use case for multiple designated revokers?

Alternatively the revokers could be listed in a separate tab in the details dialog.

There could be several designated revokers, and it's a direct key signature.
So it's like a certification, but not linked to a user ID, but to the key.
Therefor it can't be stored in one field.

Also required for an actium feature with UI.

Brainpool Cert on Disk is not relevant. Disable backup function for this case.

With Ingo's suggestions it could look like this.

Optimization requests:

The action shouldn't be enabled for keys not meeting the requirements.

This sounds good.
Will this checks be done on opening the context menu for a private key?

Of course, it should be possible to toggle "disabled" in Kleopatra.
A (context) menu entry "disable certificate" (or "enable certificate") should be sufficient.

When working on filters the "disabled" flag should be considered as well, see T7089.

I think we should separate this into two tasks: