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

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

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id FAA20554 for <>; Tue, 24 Sep 2002 05:03:48 -0400 (EDT)
Received: (from majordomo@localhost) by (8.11.6/8.11.3) id g8O8wgd27027 for ietf-openpgp-bks; Tue, 24 Sep 2002 01:58:42 -0700 (PDT)
Received: from ( []) by (8.11.6/8.11.3) with ESMTP id g8O8wev27020 for <>; Tue, 24 Sep 2002 01:58:40 -0700 (PDT)
Received: from (cdc-ws13 []) by (Postfix) with ESMTP id 3B7142C8E; Tue, 24 Sep 2002 10:58:40 +0200 (MET DST)
Received: (from moeller@localhost) by (8.10.2+Sun/8.10.2) id g8O8wcs03623; Tue, 24 Sep 2002 10:58:38 +0200 (MEST)
Date: Tue, 24 Sep 2002 10:58:38 +0200
From: Bodo Moeller <>
To: Michael Young <>
Cc: OpenPGP <>, Werner Koch <>
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: <00d101c2634b$1b4e2b80$>; from on Mon, Sep 23, 2002 at 05:49:34PM -0400
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>
Content-Transfer-Encoding: 8bit

On Mon, Sep 23, 2002 at 05:49:34PM -0400, Michael Young wrote:
> "Len Sassaman" <>;:

>> The question I see is this: are key expiration dates a "mandate" or a
>> "suggestion" to third parties by the key owner?

> More precisely, are expiration times rewriteable?
> I'm afraid that the answer has to be YES.  The specification has
> clearly said so for a while now, and at least one implementation
> (GnuPG) offers this capability.  If we change the rules now,
> anyone who has taken advantage of it (or set a short expiration
> time with the expectation that they can change it) will be
> seriously disappointed.

Actually, they won't!

My proposal was: When Bob signs a certificate for Alice's key (which
presumably he does only when Alice has told him that she considers her
key valid), he looks at all valid self-signatures and finds the one
for with key expiry is the furthest away.  This determines is the
maximum validity he should use for his certification (unless Alice
tells him otherwise).

So if your key has a short expiration time, you can extend it, and new
certifications will use the new expiration time.

You mentioned GnuPG.  Note that GnuPG apparently already handles key
expiration in a safe way during certification:

< From: Werner Koch <>;
< To: Jon Callas <>;
< Cc: Bodo Moeller <>;,
< 	OpenPGP <>;
< Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
< Date: Sat, 21 Sep 2002 11:59:22 +0200

< By default GnuPG uses the expiration date of the self-signature as the
< one for a key signature.  This is on Florian Weimer's request and afaik
< is sufficient for him and his use of the PGP PKI.

I hope Werner meant the *key* expiration date from the self-signature,
not the *signature* expiration date from the self-signature.  These
are different packet types.  Key expiration dates may be present only
in self-signatures according to the OpenPGP specification, so they
should be translated into signature expiration dates when certifying
keys; see Florians request at

< [My patch] is a bit more complicated because it also works around the
< protocol error in RFC 2440 related to V4 key expiration (V4 key
< expiration time is not covered by certificates because it is only
< contained in the self signature, not in the key material, in contrast
< to V3 keys): If the key to be signed is a V4 key with an expiration
< time set, a V4 signature is made which expires at that time, too (or
< even earlier).

Bodo Möller <>;
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036