This is so important that I would like to have it backported into the VSD3 branch.

Discussion results:

• Do not query keyservers only LDAP and WKD servers by default (via auto key locate), but origins should be configurable
• No notifications, not even for revocations.
• Log should go into another ticket.

Or should we make even simpler and just have an option to switch it on/off for daily update?

Some notes to self (and interested parties):

1. For updates via WKD we need email addresses but for updates via LDAP/keyserver we use the fingerprints.
2. If the keyserver is an LDAP server then we can use locate-external-keys with the fingerprint, but if the keyserver is not an LDAP server then we have to use recv-keys with the fingerprint.
3. Restricting automatic updates to LDAP and WKD would be an unnecessary disservice for Gpg4win users.
4. In VSD WKD can be disabled (by a flag for gpg.conf) which then uses auto-key-locate=local,ldap.

Conclusions:

1. Since the update via LDAP/keyserver is anyway independent of the update via WKD (i.e. we cannot use the same locate-external-keys call; see 1.) we keep using locate-external-keys for updates via WKD and recv-keys for updates via LDAP/keyserver as we do for manual updates.
2. Manual update/refresh currently doesn't check the auto-key-locate mechanisms, e.g. it always does a WKD lookup for user IDs originating from WKD, or, if configured, for all user IDs even if auto-key-locate doesn't contain WKD. Given 4. we should change this, i.e. the mechanism specified in auto-key-locate should be respected by the update (manual and automatic).

In VSD WKD can be disabled (by a flag for gpg.conf) which then uses auto-key-locate=local,ldap.

I learned (by looking at the config of vsd 3.4.0 and vsd 4.0-Beta) that this is not correct, it is auto-key-locate=local,keyserver with DisableWKD and auto-key-locate=local,keyserver,wkd without.
If locate-external-keys finds a key already on a configured keyserver (which may be ldap or not), it will not look on WKD any more, with the above setting.
So one can use locate-external-keys for lookup on all server types, but if you want to look in both locations, you need to search with different auto-key-locate settings to check if a key is available on keyserver and WKD (It's often outdated on one of them).

We always need to do two look-ups to update a certificate (provided wkd and keyserver/ldap are in auto-key-locate):

1. A look-up by fingerprint (via recv-keys + fingerprint because locate-external-keys + fingerprint only works for LDAP) because that's the only way to get an update for a specific certificate.
2. A look-up by email (via WKD) because that's the only way to get a replacement certificate for a specific certificate. In an organization context it might also be safe to do such a look-up via LDAP but that's definitely not a good idea for a random keyserver (including LDAP).

Some new questions came up while implementing this:

1. Should we do an LDAP look-up by email additionally to an LDAP look-up by fingerprint for OpenPGP keys? Reasoning: The look-up by fingerprint only updates already known keys (important for revocations and extended expiration) but it doesn't find new keys (important for key replacement).
2. The same question applies to S/MIME.

1. Should we do an LDAP look-up by email additionally to an LDAP look-up by fingerprint for OpenPGP keys?

I would say "yes", but only for OpenPGP-LDAP-server, but not for HKP. There could be to many spam keys.

2. The same question applies to S/MIME.

Also "yes". It's only internal and defined LDAP servers.

I'm a bit skeptical because one does not want to have multiple valid keys from one person. And suddenly appearing new and not certified keys would be confusing. But certify popup would be a no-go, I believe.
alexk's view is that the certificates delivered by the company's actium server are already certified and that there will not exist two valid keys for one mail address.