useless test keys and keyservers

[Neil Williams]

On Monday 28 February 2005 4:53 pm, Randy Burns wrote:
> Could some keys be flagged, to not to be deleted ever? Keep a
> list of such keys for your keyserver (that would propagate with
> synchronization)? Why not?

Which? Who decides? 

> Examples:
>
> 0x614239DC 9/7/2000 [expired: 1/1/2001)] PGP Security Software
> Release Key 2000
>
> 0xB0C6598E 1/2/2001 [expired: 1/1/2002)] PGP Security Software
> Release Key 2001
>
> I think so.

But signatures made by those keys will still be around in 5 years time and 
people will want to know who the signatory was.

All keys need to be kept - you can't tell if a key is out of use simply by 
waiting for the owner to respond. If the key owner has lost the passphrase or 
simply moved email account, the key is orphaned but there is no easy way of 
detecting these.

> Or, maybe, have two kinds of keyservers--expiring database
> keyservers and non-expiring database keyservers?

As I said, if you do this, the expiring keyserver is prevented from every 
synchronising with the non-expiring and that means everyone using the 
expiring keyserver has to check the non-expiring one anyway.

> > 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.
>
> Isn't that something to be aware of in any case?

No, because if the key is never deleted from the keyserver, uploading an 
unrevoked version doesn't UNDO the revocation. A revoked key stays revoked.

> > 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
> > secret.
>
> I think it's the responsibility of the person who revoked it to
> to keep the revocations out there.

And how are they meant to do that if the keyserver deletes it?

> Once nobody has searched for a 
> key in five years, however, why have it in the database, revoked
> or not?

That requires massive logs of which keys have been searched and then you 
include all those that search for "Joe Bloggs" or "0xDEADBEEF" - they get 
lots of hits, but do all of those count?

> Fine. I'm not opposed to having both types of keyserver.

I don't want any keyserver to delete anything - even if the owner doesn't want 
it around there are others who might, particularly if the key has made any 
kind of public signature.

Useless test keys are a problem, agreed, but creating an automated filter that 
can tell the difference is v.hard.

If keys start disappearing from keyservers when they are still in use, we'll 
all end up having to use keys on personal websites and the whole thing 
becomes even more burdensome.

> Also, 
> since anybody can upload the keys. If your key is signed by
> twenty keys, then you could keep those keys in circulation along
> with your own if you notice that too many of the signatures on
> your key are listed as "unknown."

?? What is the point of that?? People sign my key without any prompting and 
without any verification already. (Note to anyone reading this: Please do NOT 
sign my key until we meet face to face.)

> Just an idea. But, if PGP ever gains wide use--to the point where
> 200 million internet users know what it is and how to use
> it--then something will need to be done to prune back all the
> dead keys, I would think.


-- 

Neil Williams
=============
http://www.dcglug.org.uk/
http://www.nosoftwarepatents.com/
http://sourceforge.net/projects/isbnsearch/
http://www.neil.williamsleesmill.me.uk/
http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3

-------------- 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/f2763c45/attachment.pgp