Re: [Sks-devel] 0xd5920e937cc1e39b shows signatures with 0xca57ad7c continuing?

[Jeffrey Johnson]

On May 30, 2012, at 10:58 PM, John Clizbe <address@hidden> wrote:

> Jeffrey Johnson wrote:
>> 
>> Its the expired robo-signatures on existing pubkeys, not
>> the pubkeys, that need filtering. There is also a need to
>> delete pubkeys
>> 
>> Is there a solution that can filter out specific expired
>> signatures on pub keys that can be gossip'd efficiently?
>> 
>> AFAIK additional certification signatures are accumulated
>> and the pubkeys are then re-distributed and re-merged.
>> 
>> How should one block distributing a specific pubkey's expired signatures
>> on all existing pubkeys efficiently?
> 
> <lots of top and bottom posting mix snipped>
> 
> I'm with Rob. The keyservers should always host full certificates. Once we
> start expiring keys or modifying them by removing bits, we become the
> Untrusted Keyserver Cabal. Many would abandon us, probably forking to create a
> new keyserver network of unmodified keys. IMO, leaving SKS to become this
> century's PKS.

I don't disagree _EXCEPT_ when its a robo-signer which is
arguably adding signatures with 2 week expiries for years
and years and years for not much purpose.

Why should clients be forced to clean their pubkeys (and
servers to propagate the changes when pub keys are resigned)
because there's a robot participating in the SKS key servers?

> 
> Now, that doesn't mean we always have to serve full certificates to clients.
> 
> &options=clean -- much like GnuPG, remove unusable userIDs and sigs, remove
>        duplicate signatures keeping the most recent, remove expired
>        signatures
> 
> &options=minimal -- This removes all signatures except the most recent
>        self-signature on each user ID. Also alá GnuPG
> 
> &options=no-uat -- remove User photos and other BLOB data and accompanying
>        signatures
> 

Now you're talking ;-)

Can the filtering also be automated on upload as well as download?
That at least stops the drip drip drip as new signatures continue to
be added.

> These have the unfortunate side-effect of requiring the addition of crypto to
> handle the validation, but we'd only be doing it on lookup?op=get instead of
> every time we processed the key. And HEY! the trunk is updated to the latest
> cryptokit, 1.5.
> 

Why is crypto needed? It's a set of RFC 2440/4880
expired packets that match a pubkey fingerprint that
need to be dropped when retrieved: parsing is needed
but not crypto afaik.

73 de Jeff