recommendation for key servers

Andrew Gallagher andrewg at
Fri Jun 25 16:00:45 CEST 2021

On 25/06/2021 11:08, Werner Koch via Gnupg-devel wrote:
> On Fri, 25 Jun 2021 08:00, Jan Girlich said:
>> most PGP tools default to these days.
> Which unfortunately is a non-OpenPGP compliant keyserver and not syncing
> with other keyservers.  It has the same problems as the keyserver
> from the early 2000 years.  I would suggest not to use keyservers for key
> discovery but install a web key directory or an internal LDAP server or
> use the AD.

I agree, WKD should be the first choice method to publish your own key, 
so long as you or someone PGP-friendly is in charge of your email domain 
(it's no use for gmail addresses, for example). But implementing WKD 
yourself does not help you discover other people's keys, unless you both 
belong to the same organisation (same applies to AD, LDAP etc).

Most modern software will check WKD regardless of your keyserver 
settings, so if it is in use by your correspondent's email domain, it 
should Just Work. But for the majority of users, you still have to fall 
back to another discovery method.

The keystore trilemma is not yet solved. You can have two out of three 
of decentralisation, universality, and abuse-resistance. WKD is 
decentralised and abuse-resistant but is not universal. 
is universal and abuse-resistant but highly centralised (and 
functionally limited). Synchronising keyservers (SKS and Hockeypuck) are 
decentralised and universal but abuse-prone.

Signature attestations will help tackle many of the abuse (and 
functional limitation) issues, if we can get them standardised in a 
future openpgp update (rfc4880tris?). But we will probably have to live 
with more than one system for the foreseeable future, given the 
different compromises required.

Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the Gnupg-devel mailing list