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

Len Sassaman <rabbi@abditum.com> Tue, 24 September 2002 18:51 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 OAA08907 for <openpgp-archive@lists.ietf.org>; Tue, 24 Sep 2002 14:51:33 -0400 (EDT)
Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8OIetd04439 for ietf-openpgp-bks; Tue, 24 Sep 2002 11:40:55 -0700 (PDT)
Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OIerv04426 for <ietf-openpgp@imc.org>; Tue, 24 Sep 2002 11:40:53 -0700 (PDT)
Received: by thetis.deor.org (Postfix, from userid 500) id E7F2E45026; Tue, 24 Sep 2002 11:40:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id D398348023; Tue, 24 Sep 2002 11:40:53 -0700 (PDT)
Date: Tue, 24 Sep 2002 11:40:53 -0700
From: Len Sassaman <rabbi@abditum.com>
X-Sender: <rabbi@thetis.deor.org>
To: Michael Young <mwy-opgp97@the-youngs.org>
Cc: OpenPGP <ietf-openpgp@imc.org>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
In-Reply-To: <003d01c263f1$f92f73e0$f0c12609@transarc.ibm.com>
Message-ID: <Pine.LNX.4.30.QNWS.0209241135410.19163-100000@thetis.deor.org>
X-AIM: Elom777
X-icq: 10735603
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
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>

On Tue, 24 Sep 2002, Michael Young wrote:

> Given that this is how they work, I'd really like to see language
> in the expiration time section noting that they may be rewritten,
> and that as such, they do not have any revocation-like effects.
> Yes, this appears elsewhere, but someone reading the spec may
> not put the pieces together, and make assumptions on how
> expirations work (based on other systems or their intuition).
> I can draft something if you'd like.

This is what I was asking for in my previous message. In the case that
expired keys can be brought back from the dead, (which is the current
behavior), we need to make it clear that expirations are merely an
indication that the key may no longer be in use, and have no security
properties.