Expiration semantics (Re: draft-ietf-openpgp-rfc2440bis-06.txt)

"Michael Young" <mwy-opgp97@the-youngs.org> Mon, 23 September 2002 19:59 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 PAA22720 for <openpgp-archive@lists.ietf.org>; Mon, 23 Sep 2002 15:59:29 -0400 (EDT)
Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NJqH912897 for ietf-openpgp-bks; Mon, 23 Sep 2002 12:52:17 -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 g8NJqGv12892 for <ietf-openpgp@imc.org>; Mon, 23 Sep 2002 12:52:16 -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 PAA28436 for <ietf-openpgp@imc.org>; Mon, 23 Sep 2002 15:38:41 -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 PAA17083 for <ietf-openpgp@imc.org>; Mon, 23 Sep 2002 15:52:01 -0400 (EDT)
Message-ID: <00b701c2633a$6c5a37a0$f0c12609@transarc.ibm.com>
From: "Michael Young" <mwy-opgp97@the-youngs.org>
To: "OpenPGP" <ietf-openpgp@imc.org>
References: <B9B3FFC0.9722%jon@callas.org><20020923082334.A28473@cdc.informatik.tu-darmstadt.de> <sjm65wwyfnc.fsf@kikki.mit.edu>
Subject: Expiration semantics (Re: draft-ietf-openpgp-rfc2440bis-06.txt)
Date: Mon, 23 Sep 2002 15:50:06 -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: Expiration semantics (Re: draft-ietf-openpgp-rfc2440bis-06.txt)

From: "Derek Atkins" <derek@ihtfp.com>;
> A bad guy gets a copy of my private key..  If there is a key
> expiration then they cannot keep it alive indefinitely.  Or is key
> compromise not an attack you care about? ;)

No.

If you allow self-signatures to be rewritten with different
expiration times, then no, key COMPROMISE is NOT an attack
that the expiration time can ever mitigate.  Revocation
is the only option.

Now, it WOULD HAVE been reasonable to outright disallow multiple
self-signatures with different expiration times.  Then, the presence
of multiple expiration times could be taken as a clear sign of
compromise.  I would favor this approach, but others clearly do not,
and the spec has clearly allowed rewriting expiration times.

The usage pattern Jon Callas described does help deal with LOST keys,
though, preventing them from being used by legitimate clients.  In
the unlikely event that Jon loses his key, the flood of mail encrypted
to it will end at his most recently chosen expiration time :-).

This applies primarily to encryption.  I suppose it might also prevent
some fool from signing Jon's key (without asking him) after he has
lost it, but I feel no need to protect such fools.  So, I must admit
that I don't understand why Jon wants this to apply to main keys;
couldn't he update the expiration time in the binding signature for
his encryption keys?  If he has a "dead-man's switch" on all of his
subkeys, what more does he get from having the main key expire?

I would ask that the spec include some language to the sections on
expiration times to remind the reader that they can be rewritten, and
that clients should abide by them but not depend on them to limit
compromise.  (The right to rewrite appears elsewhere, but its
consequences may not immediately occur to someone looking at the
expiration time description.)

[As for the Bodo Moeller's original question, I mostly side with Jon.
Certifications are statements about the ownership of a key, not its
lifetime; it should be legal to make a certification that will outlast
the key's (CURRENT) expiration time.  That said, I wouldn't
strenuously object to mentioning that clients might WANT to consider
the key expiration time when making a new certification.]

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

iQA/AwUBPY9wQFMkvpTT8vCGEQL4qQCg3YUnyW9k13AUwS5sc7R0TXSbyjAAn36s
RX8JolyLTC9pvZHdpN18GeJj
=w7Hv
-----END PGP SIGNATURE-----