+ photo IDs (Re: GnuPG 1.1.91 released)

David Shaw dshaw at
Thu Aug 15 23:48:02 CEST 2002

On Thu, Aug 15, 2002 at 02:22:35PM -0400, Jason Harris wrote:
> On Wed, Aug 14, 2002 at 10:35:57PM -0400, David Shaw wrote:

[ the HKP destroying multiple subkeys bug ]

> > That would be nice.  Many people have lost keys to this bug, and HKP
> > keyservers are mostly worthless for serious use because of it.  Even
> > just a patch to discard any subkeys after the first would be fine, and
> > a proper fix can come later.
> (I haven't tried it yet, but I thought the new GPG feature matched the
> lone subkey signature to the proper subkey (by cryptographically
> verifying it).  Without the benefit of crypto, pks can't _guarantee_
> it will delete all but the "right" subkey.  Ouch!)
> Deleting additional subkeys, even when they have lost all their
> signatures _and any revocation certs._, from the bulk of the world's
> public keyservers still doesn't seem right to me.  I think such
> subkeys still have value, even if one has to use a fingerprint
> (pgpring now prints them) to verify or go into expert mode to use
> an unsigned subkey.  Perhaps you well know that GPG can't do anything
> with unsigned subkeys (whereas I still haven't checked into it).
> If so, I would argue for an expert mode that would let one use
> unsigned keys (or those with bad signatures).  With a verified
> fingerprint, who needs a signature?

Unsigned subkeys are not subkeys.  Until they are signed, they are
random blobs of data that just happen to look like something

Returning subkeys without signatures violates the RFC.  No program is
required to accept such a key, much less make use of it.  I got tired
of dealing with the problem, so I did some diddling to limit the
damage of the keyserver bug on the GnuPG side.  However, my GnuPG
feature does not help those people using any version of PGP, who can't
use these corrupt keys *at all*.

People want to use a keyserver to upload and download keys to.  They
don't want to find out after the upload that the keyserver has eaten
their key, so they can now change over to a telephone exchange of
fingerprints to work around the problem.  If they have PGP, they have
no alternative to giving up, throwing away all of the signatures they
tried so hard to get and start over.

Supporting photo IDs on the keyserver is nice work, don't get me
wrong, but it's not nearly as important in the grand scheme of things
of not destroying keys.  Basic stability before features.

If you can't implement a complete fix right now (I am not familiar
with the guts of pksd, but I understand there is some issue with the
internal data structures only expecting a single subkey), then at
least drop the additional subkeys that would be corrupted before
adding the key to the database.  You can even warn the user you are
doing it, so there is nothing sneaky going on.  You owe it to your
"customers" to not ruin keys they send to you.


   David Shaw  |  dshaw at  |  WWW
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

More information about the Gnupg-devel mailing list