sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Scott Grayban
Subject: Re: [Sks-devel] IPv6 peering; keydumps annoyingly large
Date: Wed, 01 Jun 2011 15:06:08 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.23) Gecko/20090812 Lightning/0.9.4-Inverse Thunderbird/2.0.0.23 Mnenhy/0.7.5.0

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

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

Scott




reply via email to

[Prev in Thread] Current Thread [Next in Thread]