Re: [Sks-devel] IPv6 peering; keydumps annoyingly large

[Daniel Kahn Gillmor]

On 06/01/2011 01:14 PM, Xian Stannard wrote:
> I can see that it is bad to loose keys that are in use, but why must
> every key from day zero be kept? The deletion need not be probibitive of
> the key being uploaded again: that could trigger it to be re-propagated.

I have (locally) a copy of key X from back when it was created; it had
no expiration date then.

the holder of X put an expiration date on (expires at time T) it and
uploaded it to the keyserver network.

The keyserver network propagates that key around.

Some time in the future, after time T, i decide i'll refresh that key
from the keyservers.

Clearly, if the keyservers are going to help me discover that X is now
expired, they need to keep around this ancient key that has an
expiration date well in the past.

Can you propose a category of key that does *not* have a scenario like this?

> If the complete set were to be split into clearly defined subsets,
> couldn't the fast set reconciliation could occur between these subsets
> just as quickly. Servers could carry multiple subsets to make sure that
> no particular subset lacked in redundancy? Could the current servers be
> thought of as holding all subsets?

what subsetting would you choose?  It seems trivial to do subsetting
based on, say, the first N digits in the fingerprint.  But i'm not sure
what we gain -- if someone uploads a key to a keyserver that does not
belong in their "managed subsets", what should that keyserver do with it?

> I'm guessing that one of the design aims is that the network of servers
> needs to be redundant enough so that it is very hard to kill enough of
> them to start losing access to keys.

Yes, that's certainly one of the main goals.

        --dkg

signature.asc
Description: OpenPGP digital signature