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

"Richie Laager" <rlaager@wiktel.com> Mon, 23 September 2002 17:55 UTC

Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18565 for <openpgp-archive@lists.ietf.org>; Mon, 23 Sep 2002 13:55:50 -0400 (EDT)
Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NHmOq09781 for ietf-openpgp-bks; Mon, 23 Sep 2002 10:48:24 -0700 (PDT)
Received: from maild1.wiktel.com (maild1.wiktel.com [204.221.145.237]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NHmMv09776 for <ietf-openpgp@imc.org>; Mon, 23 Sep 2002 10:48:23 -0700 (PDT)
Received: from virus3.wiktel.com (virus3.wiktel.com [204.221.145.233]) by maild1.wiktel.com (8.11.6/8.11.6) with SMTP id g8NHmKS04529 for <ietf-openpgp@imc.org>; Mon, 23 Sep 2002 12:48:20 -0500
Received: from smtp2.wiktel.com ([204.221.145.238]) by virus3.wiktel.com (NAVGW 2.5.2.9) with SMTP id M2002092312402211534 ; Mon, 23 Sep 2002 12:40:22 -0500
Received: from NB1131 ([146.57.166.32]) (authenticated) by smtp2.wiktel.com (8.11.6/8.11.6) with ESMTP id g8NHmDh28285; Mon, 23 Sep 2002 12:48:13 -0500
From: "Richie Laager" <rlaager@wiktel.com>
To: "'Bodo Moeller'" <moeller@cdc.informatik.tu-darmstadt.de>, "'Derek Atkins'" <derek@ihtfp.com>
Cc: "'Jon Callas'" <jon@callas.org>, "'OpenPGP'" <ietf-openpgp@imc.org>
Subject: RE: draft-ietf-openpgp-rfc2440bis-06.txt
Date: Mon, 23 Sep 2002 12:48:16 -0500
Organization: Wikstrom Telecom Internet
Message-ID: <000e01c26329$65730180$20a63992@umcrookston.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <20020923160102.A3035@cdc.informatik.tu-darmstadt.de>
Importance: Normal
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Content-Transfer-Encoding: 7bit

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> -----Original Message-----
> From: owner-ietf-openpgp@mail.imc.org 
> [mailto:owner-ietf-openpgp@mail.imc.org] On Behalf Of Bodo Moeller
> Sent: Monday, September 23, 2002 9:01 AM
> To: Derek Atkins
> Cc: Jon Callas; OpenPGP
> Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
> 
> On Mon, Sep 23, 2002 at 09:55:19AM -0400, Derek Atkins 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:

IIRC, key expirations are stored in the self-signature. So, a PGP
client could take all of the valid self-signatures, and compare
expiration dates. The oldest one would be honored.

This means that you cannot extend the key expiration. However, if you
don't want an attacker to be able to extend the key expiration if he
or she has the private key, this also means that the legitimate owner
of key cannot be allowed to extend the expiration date.

There is another large flaw with this plan. An attacker would only
need to revoke the self-signature, thus making it invalid. So, for
the meaning of this discussion, a "valid self-signature" would be one
that is correct in cryptographic terms, but revocations are ignored.

Deleting the other self-signatures would work, but since keyservers
only add to a key, synchronization with a keyserver could defeat this
attack method. However, if we ever implement the "no-modify" flag,
there is no reason the attacker (with possession of the private key)
couldn't send the key to the keyserver with the other signatures
deleted and the "no-modify" flag set. So, this may require that
keyservers maintain all self-signatures, even if the "no-modify" flag
is set.


So, to recap, if you ignore my implementation notes, the following
choice needs to be made:
1. Is extending a key expiration date by a key's owner a REQUIRED
action. If not, this is feasible. If so, I can't think of a way to do
it.

Richard Laager

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBPY9T3231OrleHxvOEQII8gCfWwIaXS/eLAy7hnouhI5j2ZXXobIAmgLJ
DkNjYcTIJ/Yb4Gz6QdJ3v5DQ
=cJQr
-----END PGP SIGNATURE-----