Re: More on key expiration policy (Re: draft-ietf-openpgp-rfc2440bis-06.txt)

Bodo Moeller <> Tue, 24 September 2002 09:31 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id FAA20857 for <>; Tue, 24 Sep 2002 05:31:25 -0400 (EDT)
Received: (from majordomo@localhost) by (8.11.6/8.11.3) id g8O9LWj29532 for ietf-openpgp-bks; Tue, 24 Sep 2002 02:21:32 -0700 (PDT)
Received: from ( []) by (8.11.6/8.11.3) with ESMTP id g8O9LUv29528 for <>; Tue, 24 Sep 2002 02:21:30 -0700 (PDT)
Received: from (cdc-ws13 []) by (Postfix) with ESMTP id 2101C2C8E; Tue, 24 Sep 2002 11:21:30 +0200 (MET DST)
Received: (from moeller@localhost) by (8.10.2+Sun/8.10.2) id g8O9LTb03640; Tue, 24 Sep 2002 11:21:29 +0200 (MEST)
Date: Tue, 24 Sep 2002 11:21:28 +0200
From: Bodo Moeller <>
To: Len Sassaman <>
Cc: Michael Young <>, OpenPGP <>
Subject: Re: More on key expiration policy (Re: draft-ietf-openpgp-rfc2440bis-06.txt)
Message-ID: <>
References: <00d101c2634b$1b4e2b80$> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <>; from on Mon, Sep 23, 2002 at 04:44:23PM -0700
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>
Content-Transfer-Encoding: 8bit

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 <>;
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036