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

Jon Callas <jon@callas.org> Sat, 21 September 2002 23:15 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 TAA18786 for <openpgp-archive@lists.ietf.org>; Sat, 21 Sep 2002 19:15:16 -0400 (EDT)
Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8LMrOc02767 for ietf-openpgp-bks; Sat, 21 Sep 2002 15:53:24 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8LMrNv02761 for <ietf-openpgp@imc.org>; Sat, 21 Sep 2002 15:53:23 -0700 (PDT)
Received: from [63.73.97.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Sat, 21 Sep 2002 15:53:24 -0700
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Sat, 21 Sep 2002 15:53:25 -0700
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
From: Jon Callas <jon@callas.org>
To: Bodo Moeller <moeller@cdc.informatik.tu-darmstadt.de>
CC: OpenPGP <ietf-openpgp@imc.org>
Message-ID: <B9B24675.9692%jon@callas.org>
In-Reply-To: <20020921235451.A27418@cdc.informatik.tu-darmstadt.de>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
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

On 9/21/02 2:54 PM, "Bodo Moeller" <moeller@cdc.informatik.tu-darmstadt.de>;
wrote:

> And assuming there *is* some point in doing self-signature updates
> like this, whatever it may be, you should use signature expiration
> time sub-packets, not key expiration sub-packets: it's just the
> self-signatures that you want to expire, not the key.  So there is no
> conflict with the proposed workaround for the key expiration protocol
> failure.

What I want is something of a dead-man's switch on my own key (and on other
people's -- Werner is correct in noting that this requires client work,
server work, and there are a lot of cool features you can load on this). If
someone stops using their key, then it expires after some reasonable time,
whether that reasonable time is measured in hours, days, or months.

On the flip side of this, let's imagine that I certify Alice's key. When I
certify it, I'm stating that I believe it belongs to her. If she has a
dead-woman's switch on her key, it doesn't change my statement. If I wanted
to limit the duration of my statement, that option was available to me. If
Alice permits her key to expire, I still believe it's her key! It may be
expired, but it's still her key. She could always un-expire it by putting a
new self-sig on it. If I don't like all of this, I always have the option of
revoking my signature, as well.

    Jon