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

Bodo Moeller <> Mon, 23 September 2002 18:10 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id OAA19201 for <>; Mon, 23 Sep 2002 14:10:00 -0400 (EDT)
Received: (from majordomo@localhost) by (8.11.6/8.11.3) id g8NI2vh10129 for ietf-openpgp-bks; Mon, 23 Sep 2002 11:02:57 -0700 (PDT)
Received: from ( []) by (8.11.6/8.11.3) with ESMTP id g8NI2tv10125 for <>; Mon, 23 Sep 2002 11:02:55 -0700 (PDT)
Received: from (cdc-ws13 []) by (Postfix) with ESMTP id 87F672C8E; Mon, 23 Sep 2002 20:02:56 +0200 (MET DST)
Received: (from moeller@localhost) by (8.10.2+Sun/8.10.2) id g8NI2st03502; Mon, 23 Sep 2002 20:02:54 +0200 (MEST)
Date: Mon, 23 Sep 2002 20:02:54 +0200
From: Bodo Moeller <>
To: Richie Laager <>
Cc: "'Derek Atkins'" <>, "'Jon Callas'" <>, "'OpenPGP'" <>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
Message-ID: <>
References: <> <000e01c26329$65730180$>
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: <000e01c26329$65730180$>; from on Mon, Sep 23, 2002 at 12:48:16PM -0500
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>
Content-Transfer-Encoding: 8bit

On Mon, Sep 23, 2002 at 12:48:16PM -0500, Richie Laager wrote:

>> Yes he can -- this is exactly the problem [1] that I want to solve
>> with my suggested change to the specification.  The way Jon wants
>> to use key expiration, the bad guy can keep the key alive
>> indefinitely. I call this a protocol failure, he calls it a
>> feature.

> I've been following this thread somewhat, and I have the following
> suggestion: [...]

Did you read my original message from the mailing list archives?
There is a simple workaround for the protocol failure, which does
not have the problems of your proposal: whenever someone certifies
someone else's key, then if this key has an expiration time set, the
certification signature should get an expiration time too such that
the signature's validity period extends no longer into the future than
the key's validity period.

(Obviously if Alice specifically asks Bob to certify her key for a
longer period, he can do so, but we need a default for the typical
case that there is no out-of-band information on this.)

Of course the one problem we cannot avoid is that the legitimate owner
of the key cannot keep the key alive indefinitely.  This is because
this "problem" is exactly the security feature that me and Florian
Weimer and Derek Atkins want to have: we don't want the bad guy to be
able to unexpire the key if he gets hold of the secret key.

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