Re: draft-ietf-openpgp-rfc2440bis-06.txt

Bodo Moeller <> Wed, 25 September 2002 11:14 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id HAA21817 for <>; Wed, 25 Sep 2002 07:14:14 -0400 (EDT)
Received: (from majordomo@localhost) by (8.11.6/8.11.3) id g8PB5p320507 for ietf-openpgp-bks; Wed, 25 Sep 2002 04:05:51 -0700 (PDT)
Received: from ( []) by (8.11.6/8.11.3) with ESMTP id g8PB5ov20499 for <>; Wed, 25 Sep 2002 04:05:50 -0700 (PDT)
Received: from (cdc-ws13 []) by (Postfix) with ESMTP id 8BD2E2C93; Wed, 25 Sep 2002 13:05:49 +0200 (MET DST)
Received: (from moeller@localhost) by (8.10.2+Sun/8.10.2) id g8PB5l604730; Wed, 25 Sep 2002 13:05:47 +0200 (MEST)
Date: Wed, 25 Sep 2002 13:05:47 +0200
From: Bodo Moeller <>
To: Jon Callas <>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
Message-ID: <>
References: <>
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 Tue, Sep 24, 2002 at 04:05:32PM -0700
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>
Content-Transfer-Encoding: 8bit

On Tue, Sep 24, 2002 at 04:05:32PM -0700, Jon Callas wrote:
> Bodo Moeller <>de>:

>> As I pointed out, you can use *self-signature* expiration (subpacket
>> type 3) for many purposes, and use *key* expiration (subpacket type 9)
>> for cases where you really want the key to expire [...] such that the
>> bad guy cannot unexpire the key.  What speaks against this?

> They mean separate things. A signature expiration on a self-signature
> expires the validity of that signature. If you have, for example, a key with
> two user names, expiration of that signature effectively expires that user
> id. They key expiration makes the whole key expire. If you did it with
> signature expirations, you'd have to manage every user id separately.

Now it all fits together.  It turns out that you can have it your way
and I can have it mine.

In your scenario, you need to set key expiration times in *direct-key*
self-signatures, and you want key lifetime to be extensible by

In my scenario, if you want expiration that cannot be undone, you set
a key expiration time in each *certification* self-signature.

All the time, you were talking about key expiration time sub-packets
in direct-key signatures while I was talking about key expiration time
sub-packets in certification signatures.  It's only the latter type of
expiration that should carry over into certifications by others.

Earlier I described my proposal like this:

     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).

This procedure should be changed as follows.  To determine the maximum
validity for his certification, Bob takes into account any key
expiration times found in *certification* self-signatures for the
respective user ID; not the key expiration times found in *direct-key*
self-signatures (these are relevant only for determining if the key is
currently valid).

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