On Mon, Sep 23, 2002 at 04:44:23PM -0700, Len Sassaman wrote:
Wasn't the original suggestion that keys expire at the earliest expiration
time, and later expiration dates be ignored?
No, that was not my proposal. This was a suggestion by Richie Laager,
but actually it's incompatible with some details of my proposal:
it's okay for me to let key lifetime be extensible, it's just that
certifications should be valid only for the currently defined lifetime
of the key (during certification) so that all certifications become
worthless if the user lets the key expire.
It would be safer to have a fixed key expiry date as in version 3 keys
(but to have it covered by the fingerprint, unlike version 3).
However, I want compatibility with the version 4 format, and this
makes extensible key lifetime acceptable within my proposal.
That would address the
problem.
But not actually solve it: in general you cannot rely on seeing all
packets that are available on some keyserver, or that someone tries to
send to some keyserver (cf. my remarks on non-monotonous proof systems
elsewhere in this thread; this is essentially the same problem as with
revocation). The "earliest expiration time" according to your keyring
may not be the actual earliest expiration time.
--
Bodo Möller <moeller(_at_)cdc(_dot_)informatik(_dot_)tu-darmstadt(_dot_)de>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036