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

[Gabor Kiss]

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

Actually it is not true that SKS does not modify certs.
Let K(S1,S2,S3) denote a K key signed with S1, S2, S3 signatures.
If an SKS node stores K(S1,S2) and user sends in an update K(S3)
SKS merges the sets of signatures and stores K(S1,S2,S3).
That -- strictly speaking -- differs from the user sent in
(but matches user's expectations).

So I suggest two modifications of the rules.

1. A key server must refuse if user sends update containing expired
signatures, e.g. K(S1,S2,E3) but it should reply a polite error message
asking him/her to remove expired sigs manually before upload.

2. When a key server holding K(S1,E3) receives update K(S1,S2)
it must drop expired sigs in the merging process.
This also matches what user expects, doesn't it?

Gabor