useless test keys and keyservers

[Randy Burns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

via private email:

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.

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

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?

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.

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

PGP Global Directory could be that, except that they limit keys
to one key per email address.

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

Isn't that something to be aware of in any case?

> 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. Once nobody has searched for a
key in five years, however, why have it in the database, revoked
or not?

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

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

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

Fine. I'm not opposed to having both types of keyserver. 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."

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.

Best,
Randy


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1rc2 (MingW32) - GPGshell v3.32
Comment: Public Keys: www.geocities.com/burns98/pgp

iD8DBQFCI0szO1wFkBRYxW8RA60IAJ0XQ+sMSUpRtO3uj/g+PuBoe5ziLgCfVoJJ
1sd13DArml29lMXtZj23eqo=
=qZ6M
-----END PGP SIGNATURE-----