GNUPG and PKI compatibility (?)

John Clizbe John at
Fri Feb 6 02:20:02 CET 2009

gerry_lowry (alliston ontario canada) wrote:
> These may be some keyservers to use for looking up keys with "gpg --recv-key"
>     keyserver hkp:// 
>     keyserver hkp:// 
>     keyserver hkp:// (random server) 
>     keyserver hkp:// 

An "interesting" assortment, but the only one I'd keep is

Here's why: The original purpose of was to be a set of
subkey safe keyservers, PKS servers that were patched to not mangle V4 keys and
a few of the new SKS servers. Most all maintained PKS boxes have converted to SKS.

The current collection is a subset of the SKS network:,,,,,
and gives me all of these servers
and more. BTW, this is also a DNS round robin... you get a random server of the
six. Any of these are likely to be included in It is, in general, very poor netiquette to steer traffic to a
single server when load-balancing mechanisms are well-known and available. The
more widely distributed that traffic balancing is, the better for all concerned.
If, for some reason, that single server is down, a user's keyserver operation
will fail. The pooled round-robins minimize this risk. This server is also part
of and ~50% likely to be part of The *BEST*CHOICE* of this bunch. it is a DNS
round-robin consisting of 20 SKS servers that a) are up, and b) are synchronized
with the rest of the SKS network. 20 randomly chosen from 40-50 that normally
make up the greater pool of SKS servers and the list is updated twice per day.

The win is the b) part - because of the manner changes are distributed in the
SKS network, all servers have nearly or soon to be (within minutes) identical
copies of the entire database. I find that most times, my keyserver's 25+ recon
partners have zero differences from my copy of the database. Said another way,
outside of networking issues such as RTT (round trip time),

Sharing the load among all servers is the best approach for all - server
operators and users. Bad, Bad, Bad, Bad idea. Perennial favorite for worst
recommendation of keyserver.

As a friend of mine said on this list two days ago, "Friends don't let friends
use  It is irreparably broken for modern OpenPGP keys."

"How is it broken?" you may ask. PKS does not handle V4 key features well.
Notable examples of mangled features are multiple subkeys, a revoked subkey (tag
0x28), duplicate keyids, direct key signatures (tag 0x1F), revocation signatures
on userids (tag 0x30), or photo IDs.

There is also no development or maintenance being done on the PKS platform.

Please do not recommend this server.

> Not all of the above may be up.

Your chances of a server not being up increase as the size of your pool of
servers decrease. Single server -> greatest odds of hitting a failure.

If they're listed as part of, they will most likely be
up (or were up within the last 12 hours or so)

Note: this list looks like a selection of keyserver directives from a GnuPG
configuration file, gpg.conf. Unless David or Werner changed the logic and I
missed the commit, only the last uncommented keyserver directive will be used by
GnuPG. There is no iteration over a list of keyservers alá PGP. You get one
active keyserver statement, hence being the best

John P. Clizbe                      Inet:John (a)
You can't spell fiasco without SCO. hkp://  or
     mailto:pgp-public-keys at

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 680 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090205/c3f6433b/attachment.pgp>

More information about the Gnupg-users mailing list