Question About Accumulated Bad Signatures in Public Key

[Daniel Kahn Gillmor]

On 07/24/2009 04:37 PM, Erik Lotspeich wrote:
> Public key servers do not seem to scrub or clean public keys.  Is it a
> reasonable thing to delete the public key and re-add it?  This doesn't
> seem to be something that most public keyservers allow or recommend.  Or
> is it normal for bad signatures to accumulate over the years and it is
> to be expected.

There is no good reason for bad signatures to show up in the first
place, but there is no good way for keyservers to drop them either, if
they do show up (by error or by malice).  Here's why.

Signatures are marked by a shorthand identifier of what key has made
them.  This ID is the last 64 bits of the key fingerprint.  Technically,
this identifier is part of an "Issuer subpacket", and it's not even
required to be included in the signature, though well-formed signatures
 do have them.  (see http://tools.ietf.org/html/rfc4880#section-5.2.3.5 )

Key fingerprints (160 bits) themselves aren't technically guaranteed to
be unique, but for all practical purposes, they currently are.  But the
last 64 bits are certainly not guaranteed to be unique, and deliberate
collisions could probably even be generated by well-financed groups.

So consider a few possible scenarios keyservers must face upon receipt
of a signature over the first User ID of key 0123456789ABCDEF, which
contains an Issuer subpacket claiming it is issued by key DEADBEEFDEADBEEF:

 * say the keyserver doesn't currently know of any key where the last 64
bits of the fingerprint match DEADBEEFDEADBEEF: should it ignore the
signature and discard it?  or should it store it for use by people who
have a copy of that public key even if it's not on the keyservers?

 * say the keyserver *does* know of a key where the last 64 bits match
DEADBEEFDEADBEEF, *and* the keyserver has the capability to
cryptographically verify the signature (an unusual keyserver these days
-- most don't at the moment).  If the signature doesn't validate, what
should it do?  it's possible that the signature was made by a
*different* DEADBEEFDEADBEEF key that the keyserver doesn't know about.
 Now should it ignore the signature and discard it?


Does this make sense why the keyservers haven't bothered to discard the
"bad" signatures?  They can't tell a bad sig from a sig from a key
they've never seen before.

You might also consider reading these pages:

  http://www.rossde.com/PGP/pgp_keyserv.html

  http://pgp.mit.edu/faq.html

The Q&A on them about deleting keys from keyservers is similarly
relevant to questions about removing specific signatures from the
keyservers.

If you're interested in more discussion about the way that keyservers
work, you should join the SKS development list <sks-devel at nongnu.org>:
http://lists.nongnu.org/mailman/listinfo/sks-devel

SKS has become the dominant free OpenPGP keyserver software, and there
is active development and discussion on that list about how a modern
keyserver can and should function.

	--dkg

PS fwiw, if you're concerned about busted signatures on FA2C849B, i only
see one such bad sig (from 9E8E7BFC in january of this year) when i
fetch the relevant keys from the public keyserver network.  That's not
too bad.

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