[cks-devl] Re: status of pgsql server

[V Alex Brennen]

Of primary interest is the verification of subkey binding signatures
and self signatures.  Most likely, I'll release a version of server
which can verify these types of signatures first, then work on the
verification of cross key signatures.  Invalid or spoofed cross
key signatures are less likely to result in direct security
compromise than faked subkey binding or self signatures (which
include User ID, expiration, and revocation data).

At the present time, I plan to check the binding and self signatures
at submission time only which should result in limited CPU usage.

My commitment to the maintenance of the cks code, and the compatibility
efforts of the openPGP standards team should allay your concerns about
future compatibility and key rejection.


        - VAB

On Tue, 28 Aug 2001, Michael Young wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
>
> From: "M. Drew Streib" <address@hidden>
> > Did you say you were planning on doing cryptographic verificaiton
> > of signatures/etc on the inbound keys? Seems very useful, although
> > it would chew a lot of cpu.
>
> I don't see much point in attempting verification.  Would you reject
> signatures from keys that are not on a server -- ones that are
> potentially valid but that *you* cannot verify?  If you can't
> verify them all, is it really worth verifying some?
>
> There are plenty of other ways to fill a keyserver with junk.
> Preventing this one doesn't seem worth the effort, unless you know of
> some broken software out there that accidentally creates this sort of
> junk now.
>
> As a general principle, I advocate having the keyservers act as simple
> storage, with as little knowledge of the material as they can get away
> with.  We already have seen keyservers that "know" too much, such that
> they wouldn't accept: multiple self-signatures; multiple subkeys;
> key-only self-signatures (for revocation); other userId flavors
> (photo); and/or, new-style RSA keys.  A server does need to know where
> signatures fall within the key/sub-item sequence in order to
> merge.  Much more than that risks failure to store the next new thing.