The meat with multiple PGP subkeys

[David Shaw]

On Tue, Jun 17, 2003 at 11:42:13PM +0200, martin f krafft wrote:
> My key, 220BC883330C4A75, has multiple encryption subkeys, and it's
> about to get another one on Friday, as my current encryption key
> expires.
> 
> A lot of people are reporting that they cannot encrypt to me, due to
> an unusable public key. It only seems to work if they use modern
> software and obtain my key from keyserver.kjsl.com:11371 or the
> various URLs where it sits.
> 
> I am already working with keyserver maintainers to get their
> keyservers up to par, but before this can be completed, I feel that
> I need to get an exact understanding of what's going on.
> 
> Could someone help me clean up this understanding?
> 
> - What is the problem with multiple subkeys?

The problem is that the PKS keyserver was not written to handle keys
with multiple subkeys.  This was around the era of PGP 5.0, RFC-2440
hadn't been published yet, and there was some uncertainty on that
topic.  So PKS was never written to handle multiple subkeys, and as an
unfortunate side effect of that, it mangled any keys it saw that did
have multiple subkeys.  On top of that, since keyservers synchronize
with each other, every other server would learn this mangled key.

Alas, PKS is still in wide use, but never got the ability to handle
multiple subkeys.  I contributed some fixes so PKS would at least not
mangle keys, but not every keyserver has upgraded.

> - Are they in accordance with the RFC (2440)?

Yes, and both PGP and GnuPG handle them correctly.  It's just this one
particular keyserver program that doesn't.

> - Are others experiencing these problems, and how do you deal with
>   them?
>
> - Is there a solution in the works?

The ultimate solution is to either fix or replace PKS.  Both of these
have been happening, with a fair edge to the "replace" camp.  There
are several different keyservers (SKS [1], ONAK [2], etc) that are
truly 2440 compliant.  SKS is probably the most mature at this point,
and can replace a PKS installation.

Note that the LDAP keyserver from PGP.com works correctly as well, but
is not a free (in cost and in freedom) product so is generally not
used as part of the public keyserver net.  The PGP folks run one at
ldap://keyserver.pgp.com, but it is not synchronized with the rest of
the servers.

A reasonable question would be "Why don't all the PKS operators
replace their server with SKS or something else?".  I don't have a
good answer to that.  It's certainly been asked.[3]

Recently, the number of working keyservers reached the point where it
became possible to establish a simple way to reach them.  Similar to
the "wwwkeys.pgp.net" round robin keyserver address, the
"subkeys.pgp.net" name will reach one of the unbroken keyservers
(keyserver.kjsl.com being one of them), ignoring the broken ones.

So, the short answer to all of this is to use "subkeys.pgp.net" as
your keyserver and you should be fine.  The next version of GnuPG will
ship with this set as the default keyserver.

David

[1] http://sks.sourceforge.net/

[2] http://www.earth.li/projectpurple/progs/onak.html

[3] http://lists.kjsl.com/pipermail/pgp-keyserver-folk/2003-March/001071.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 261 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20030617/4334114b/attachment.pgp>