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

"Michael Young" <mwy-opgp97@the-youngs.org> Mon, 23 September 2002 21:56 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 RAA26809 for <openpgp-archive@lists.ietf.org>; Mon, 23 Sep 2002 17:56:51 -0400 (EDT)
Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NLpYk16126 for ietf-openpgp-bks; Mon, 23 Sep 2002 14:51:34 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NLpWv16122 for <ietf-openpgp@imc.org>; Mon, 23 Sep 2002 14:51:32 -0700 (PDT)
Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id RAA20554 for <ietf-openpgp@imc.org>; Mon, 23 Sep 2002 17:38:08 -0400 (EDT)
Received: from mwyoung (dhcp-193-40.transarc.ibm.com [9.38.193.240]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id RAA17631 for <ietf-openpgp@imc.org>; Mon, 23 Sep 2002 17:51:29 -0400 (EDT)
Message-ID: <00d101c2634b$1b4e2b80$f0c12609@transarc.ibm.com>
From: "Michael Young" <mwy-opgp97@the-youngs.org>
To: "OpenPGP" <ietf-openpgp@imc.org>
References: <Pine.LNX.4.30.QNWS.0209231142100.22100-100000@thetis.deor.org>
Subject: More on key expiration policy (Re: draft-ietf-openpgp-rfc2440bis-06.txt)
Date: Mon, 23 Sep 2002 17:49:34 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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

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

From: "Len Sassaman" <rabbi@abditum.com>;
> Actually, in Jon's proposal, the bad guy can. If we do things Bodo's way,
> he can't.

Bodo originally suggested that clients abide by expiration times when
creating new certifications.  That alone may not prevent a compromised
key from being misused.  Yes, it would work for certifications prior
to the compromise, and for new ones where the signer gets the key
*directly* from the owner, but that still doesn't cover all cases.

Consider this scenario...
    I steal Bob's key.
    I publish it, with an updated expiration time, to an
     out-of-the-way keyserver.
    Bob's new friend Alice gets his key from this keyserver.
    Alice verifies the fingerprint with Bob, and signs his key,
     in accordance with Bodo's rules.
    Alice sends her new signature to Bob, and/or publishes it
     at my keyserver, but I steal it enroute.
    I have a signature that will outlast Bob's intended expiration.

The problem is that fingerprints don't include the expiration time.

Now, Bob *could* insist on getting a copy of Alice's signature, and
check for a mismatched expiration time.  Together, Bob and Alice could
discover that I've compromised Bob.  But this would require more care
in the keysigning process than even some very cautious people apply.

Note that disallowing rewriting won't prevent this attack, as
that also depends on someone noticing a (different) mismatch.
(If I can completely keep people from seeing key updates,
then I can defeat revocations, too, but that's a much broader
attack.)

This may be another fair argument for allowing rewriting.  If you
really wanted irrevocable expiration times, you'd want to hash them
into the fingerprint material, but it's way too late for that.

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

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQA/AwUBPY+MalMkvpTT8vCGEQLVmgCfVDZTWIpnOt2Gu1e31DPtMqaV8ekAn14H
E6TRRSoBFYuIfKzI7oiCwngd
=w8jJ
-----END PGP SIGNATURE-----