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

"Richie Laager" <rlaager@wiktel.com> Mon, 23 September 2002 21:40 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 RAA26269 for <openpgp-archive@lists.ietf.org>; Mon, 23 Sep 2002 17:40:35 -0400 (EDT)
Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NLXlC15794 for ietf-openpgp-bks; Mon, 23 Sep 2002 14:33:47 -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 g8NLXjv15788 for <ietf-openpgp@imc.org>; Mon, 23 Sep 2002 14:33:45 -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 g8NLXeS00886 for <ietf-openpgp@imc.org>; Mon, 23 Sep 2002 16:33:40 -0500
Received: from smtp1.wiktel.com ([204.221.145.236]) by virus3.wiktel.com (NAVGW 2.5.2.9) with SMTP id M2002092316254319777 ; Mon, 23 Sep 2002 16:25:43 -0500
Received: from NB1131 ([146.57.166.17]) (authenticated) by smtp1.wiktel.com (8.11.6/8.11.6) with ESMTP id g8NLXeu12772; Mon, 23 Sep 2002 16:33:40 -0500
From: "Richie Laager" <rlaager@wiktel.com>
To: "'Bodo Moeller'" <moeller@cdc.informatik.tu-darmstadt.de>
Cc: "'OpenPGP'" <ietf-openpgp@imc.org>
Subject: RE: draft-ietf-openpgp-rfc2440bis-06.txt
Date: Mon, 23 Sep 2002 16:33:36 -0500
Organization: Wikstrom Telecom Internet
Message-ID: <000001c26348$e0494ad0$11a63992@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: <20020923205729.A2899@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: Bodo Moeller [mailto:moeller@cdc.informatik.tu-darmstadt.de] 
> Sent: Monday, September 23, 2002 1:57 PM
> To: Richie Laager
> Cc: 'OpenPGP'
> Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
> 
> 
> On Mon, Sep 23, 2002 at 01:49:14PM -0500, Richie Laager wrote:
> 
> >> 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.
> 
> > How does this help? If a "bad guy" gets the private key, he can
> > simply resign everyone's key.
> 
> If the bad guy gets Alice's private key that has expired, he can
> renew Alice's self-signature on the key, but he cannot renew Bob's
> certification for Alice's key, which will have expired too
> according to my proposal.  So no-one will believe it is still
> Alice's key.

Okay. I get it now. Alice's key expires in 5 years from creating, for
example. Two years later, Bob signs Alice's. Bob's PGP client sets an
expiration date of 3 years in the future on Bob's signature on
Alice's key. That way, Bob's signature expires at the same time as
Alice's key. If an attacker gets Alice's private key and extends the
expiration, the attacker would have to regain all of the signatures.

The only flaw I can see is that if Alice sets an expiration date of
Never, gets a signature from Bob, and then sets her expiration time
to 5 years, Bob's signature will likely NOT have an expiration date.
So, an attacker could then exploit Bob's signature. In essence, this
means that someone can't shrink their key validity length (length as
in time) and still have these benefits. My proposal would allow this.
However, my proposal doesn't allow someone to extend his or her key
validity length. And, my proposal requires changes on the client side
of the recipient, while your proposal requires client side changes
for the key signer. Therefore, I'll agree that your proposal is the
best. I just wanted to contribute my thoughts and clarify my
understanding of the issue.

Richard Laager

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

iQA/AwUBPY+IsG31OrleHxvOEQL8pACgnEr+K80z6bJjZuVRN1vZA1IQjUoAoJOj
cyoxxYnf/9pDxqTuSG6xed3O
=aRsa
-----END PGP SIGNATURE-----