At 2:42 pm +0900 2000-12-18, sen_ml(_at_)eccosys(_dot_)com wrote:
one authentication-less way that occurred to me is to have keys have
life times on servers (default being 1 year perhaps?). then, though
you might have to wait a while, at least your old keys could disappear
from servers after a certain period of time.
I agree that the default should be one year. I've been calling for
this for a very long time, and I'm definitely not alone. There are so
many confused users out there on these key management points: I'm
beginning to wonder if the development community is really paying
attention to usability issues. PGP 7's Key Reconstruction is a very
nice idea, but I've tried to get some newbies to use it and their
reaction to being confronted by a dialog asking them to come up with
five questions in case they forgot their passphrase was "are you
kidding me?!"
Also consider the idea of keyservers employing "flushing routines"
for potentially "dead" keys. In one possible scenario, a key has
languished on a server (e.g. hasn't been accessed for n ticks) for
two years, has no expiration and is about to disappear as described
above. The keyserver could email it to all of the email addresses on
the key (this would encourage people to keep their userids current,
yet another extremely common key hygiene problem). If the key wasn't
updated by anyone within another time period (set by the admin), the
key would be dropped.
Storing your key on a public keyserver is a privilege, not a right.
If you can't do the most basic things to maintain it, you're not
doing anyone any good, least of all yourself if you want people to
use it.
your client software can remind you that you need to upload your key
when it gets close to the "expiration" date/time.
It would make sense if *all* OpenPGP-compliant implementations had
some basic HCI features like this: a warning when one's key is about
to expire seems extremely obvious -- or even when signatures made by
one's key on others' keys (stored on one's local keyring) are about
to expire.
Jon, perhaps expiration packets can be mentioned in 2440bis as being
potential triggers for this mechanism. Implementors could also be
encouraged to consider providing expiration warning mechanisms.
dave