Re: [Sks-devel] Re: Debian SKS packages was: [pgp-keyserver-folk] new pgp key server

[Yaron Minsky]

On Sun, 19 Sep 2004 11:33:55 -0400, David Shaw <address@hidden> wrote:
> 
> This particular one is hard to filter out since it is corrupt public
> key data.  If the public key in question is the main public key then
> the rest of the key is meaningless without it - filtering it is
> effectively like filtering out the whole key (which is what happens).
> 
> In this particular case, the corrupt key is a public subkey, so it
> could theoretically be filtered out and the key as a whole would just
> be short one subkey.... but in practice this is difficult.  The packet
> is corrupt, so we don't really know anything at this point.  In
> particular, is the length of the packet itself sane?  If not, we can't
> drop it since we don't know where the next packet starts.

Interesting.  This wouldn't be difficult from the way SKS handles
things.  Basically, SKS first parses the key down to the packet level,
which works without problems for this key.  Things like MPIs are only
looked at within the packet level.  If one such is found to be bogus,
the packet could then easily be thrown out.  I'm somewhat surprised
it's not handled similarly in GPG.

Moreover, throwing out a corrupted packet and everything that depends
on it seems like the only approach that is consistent with the SKS/PKS
style of crypto-free keyservers.  If someone decides to add an extra
bogus public subkey packet, the only thing that SKS can do in general
is include it, since it can't detect most forms of bogosity.  And it
seems like the only reasonable thing for GPG to do in this case is to
drop it.

I can certainly modify SKS to subkeys which have this particular
problem.  But I'm a touch leery of doing this piecemeal.  Does anyone
here think they know what kinds of bad packets GPG will discard, and
which it will choke on?  And what about PGP?

> With regards to your first question, this is the second subkey on a
> key, so PKS doesn't even look at it (no multiple subkey support).  I
> don't know what Jason's patched PKS does for this subkey.  It seems to
> not have the bad subkey at all (only one subkey for key 04F130BC on
> that server).

Jason, I've included you on this because I'm curious what your server
does.  How do you handle packets with corrupted MPIs?

y