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

[David Shaw]

On Sun, Sep 19, 2004 at 10:11:32AM -0400, Yaron Minsky wrote:
> Interesting.  I do remember discussing this before.  I'm not sure
> offhand what the right solution is.  A few questions come to mind:
> 
> First, does anyone know what PKS does about this?  Does it have some
> filter that tosses out packets with overlarge MPIs?  Or has the packet
> in question simply not been submitted to the PKS network?
> 
> Second, why doesn't GPG just dump the packet in question?  Generally,
> speaking, SKS doesn't look deeply into packets to make sure they're
> good, and simply assumes that GPG and similar tools will toss out bad
> packets.  This is really the principle that any non-cryptographic
> keyserver must follow (including PKS).  So is there some principle
> that makes it clear what kinds of problems GPG can filter out, and
> what it can't?

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.

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).

David

pgpb2aZM48d82.pgp
Description: PGP signature