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 _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel