useless test keys and keyservers

Neil Williams linux at
Mon Feb 28 18:16:31 CET 2005

On Monday 28 February 2005 4:18 am, Randy Burns wrote:
> I wish all pgp keys could automatically be purged from keyservers
> on the anniversary of their creation.

Sorry, I didn't check the reply address - this was meant for the list.

But then many, many keys would be unavailable at any one time. With only 365 
days a year and so many tens of thousands of keys, that's a lot of keys every 
single day.

The point with a keyserver is that the key is always available and always up 
to date. It's especially important that revoked and expired keys are 
continuously available - when someone queries for a key that has been 
revoked, it is imperative that the keyserver always gives a definitive 
answer. "Sorry, I'm waiting for that one to be sent back but last time I saw 
it, it was revoked" is not good enough.

An attacker would know the anniversary date and could put up an attacked key 
in it's place - in the lagtime before the real owner connects to the 
internet, the wrong key is in use. After all, the attacker has the key before 
it is revoked and is unlikely to knowingly refresh the key to import the 
revocation certificate so his copy will be unrevoked - he can just as easily 
put that onto the keyserver as the real owner.

Your purge could result in many attacked (and currently revoked) keys suddenly 
becoming usable again - the real owner may not keep a copy of their revoked 
key if they don't have much data that was encrypted to that key before the 
attack. The attacker certainly does have an unrevoked copy, public and 

Then you've got the whole keyserver synchronisation to consider - by your 
reasoning, the key would disappear completely from every keyserver at the 
same time! If you change the date of removal so that each keyserver purges at 
a different time, the key will be refreshed from another keyserver at next 
sync, rather than from the user so you lose the entire point of your 

> Then, key owners would know 
> that obsolete keys will eventually disappear, and know when their
> actively searched-for keys (fresh keys as well as freshly-revoked
> keys) need to be uploaded again--always just after the
> anniversary of their creation. That way, key uploads get spread
> throughout the whole year.

But many keys don't change year to year - there's nothing wrong with that. 
Just because a key doesn't change, there's no reason to think it's out of 

> Wouldn't that be a good thing? 

No, it would be a very BAD thing - it's part of the controversy over PGP GD.

If you want to use a keyserver that implements that kind of policy, fine, just 
be very careful to use a full-size keyserver to refresh your keys in case 
someone revoked their key coincidentally just before the arbitrary creation 
anniversary date. 


Neil Williams

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20050228/50717c07/attachment.pgp

More information about the Gnupg-users mailing list