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: Xian Stannard
Subject: Re: [Sks-devel] IPv6 peering; keydumps annoyingly large
Date: Thu, 02 Jun 2011 00:26:41 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/06/2011 22:45, David Shaw wrote:
> 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.
A delay between revoking and deleting should solve this; a year or few
sounds good too me. If the delay is taken from the latest of the keys
expiry date or the last revocation then it should have plenty of time to
propagate to all the users of it.

> 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.
It is an issue for me. I have a small VPS (can't afford a large one) and
don't have enough disk spare to comfortably host an SKS server.
Processor, bandwidth and RAM are enough for it though.

If I could host only part of the entire key collection (or the
collection was smaller) I would. My guess is there are other people in a
similar situation. Many many more servers hosting only part of the
collection could still achieve a higher redundancy than we currently
have. If an admin could dictate the proportion of the entire collection,
or just specify the minimum amount of disk to keep free, life would be
easier. For me anyhow.

- -- 
/Xian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJN5sqxAAoJEEPJptmhzueQdzUH/jtOalNlDXlb2efOhiuZoWTR
DTElVvU0tmROZFEJrgaVeI4EOCPaxTBgOi4ce7AWYfAmSufRleaqshFYsKgBNeF/
KgbPPb7cMyndZz5LIu+uwmPdFlSBYtAfgssmqrQAyqskB6lS7UNa7A+GbmdTDbAF
xfvvTD59ZWVO7GwROGidFMitNWWT7X/NfyxpNJeIxX4EdOZRGH9cyKB33dlz55Lx
VKNIBXJfyOxkQuVvNgtqalMfwPFDsAXGj4Yg0XP4ZN8L5SLYemih77onGhuaJFNf
GL0cTcy7zCEOrxD7cRnk92TheGp60gbsT5Vq9bVUvjU/JRBb5OW1Iq43KNxdJx8=
=qnha
-----END PGP SIGNATURE-----



reply via email to

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