On May 30, 2012, at 10:58 PM, John Clizbe <jpcli...@gingerbear.net> 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 _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
