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

[David Shaw]

On Jun 1, 2011, at 6:06 PM, Scott Grayban wrote:

> David Shaw said the following on 06/01/2011 02:45 PM:
>> On Jun 1, 2011, at 1: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.
>>> 
>> One danger is that a revoked key won't be seen as revoked by someone who 
>> needs to see it as such.  For example, let's say that I have a public key on 
>> the keyservers (call it "A"), and my secret key gets compromised.  I revoke 
>> that key, make a new one ("B"), and upload both A & B to the keyservers.
>> 
>> Now, someone who I communicated with before my key was compromised wants to 
>> get ahold of me, and so uses the only key they have: A.  They don't know 
>> that I have a new key, and checking the keyservers (gpg --refresh-keys, or 
>> similar for other programs) won't show them that A is revoked, because A got 
>> pruned from the keyserver when it was revoked.
>> 
>> Now, to be sure, we could design different ways of avoiding this issue, but 
>> personally, I'd want to see some real evidence of an upcoming problem with 
>> the keyserver DB size before going down that route.  I'm afraid I don't see 
>> a problem that needs fixing here.

> You can search the keyserver using just the email address and they would
> still get the new pub key

Sure, but that's requiring a behavioral change for all users.  They don't do 
that today.  There are years of "training" that would have to be overcome.

Requiring a behavioral change to fix something that isn't widely felt to be a 
problem in the first place seems odd to me.

But still, let's say I'm wrong and you're right: just set up a keyserver 
network that follows whatever key retention policy you desire.  The code and 
initial keydumps are publicly available.  I think it would be unfortunate, and 
risk confusing people (and confusion in a security context is usually not 
desirable), but nobody can stop you.

David