Re: Revoking Old Lost Keys

On Fri, 05 Jan 1996 23:07:19 -0800, Bruce Baugh <bruceab@teleport.com>
wrote:

>I'd like to bring up a problem I haven't seen addressed much yet, and which
>I think is going to come up with increasing frequency as PGP use spreads.

>The problem is this: how can one spread the word that an old key is no
>longer to be used when one no longer has the pass phrase, and cannot
>therefore create a revocation certificate?

[..]

Keys should have built-in expiration dates (adjustable by the user
manually the way one would change their user-id, passphrase, etc.)

PGP should give a warning when the key passes the expiration date. It
should not prevent you from using it, but should remind you that the
key is rather old, and that the owner may have moved, etc.

Users who want to extend the life of their keys should send special
certificates (at least once a year or every other year?) that tell
keyservers and those with copies of their public keys that the key is
still being used, and to update the expiration time.

Comments?

--Rob

Mutatis Mutantdis wrote:

| PGP should give a warning when the key passes the expiration date. It
| should not prevent you from using it, but should remind you that the
| key is rather old, and that the owner may have moved, etc.
| 
| Users who want to extend the life of their keys should send special
| certificates (at least once a year or every other year?) that tell
| keyservers and those with copies of their public keys that the key is
| still being used, and to update the expiration time.

	Expire should mean expire, i.e., no longer valid, useful or
useable.  If you want to have a 'depreciated after' and an expire
date, that might be useful, but it seems more like feeping creaturitis
to me.  It adds bulk to every key, when a better solution would be to
have keys automatically deprecitated some time before they are due to
expire.

	Also, the ability to extend the life of a key is fraught with
danger.  The longer a key is around, the more likely it is to become
comprimised.  The user might not be aware that the key is comprimised.
Better to have an unchangeable date.  (On a more technical level,
allowing users to change the expiry date on a key means that the key's
expiry date is not signed by the signatories, and an opponent who
comprimised a key could simply change the expiry date on that key and
send it to the servers, so that it would continue to be used, and your
opponent could continue to read all your communications.)

Adam

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume