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

David Shaw <> Tue, 24 September 2002 19:52 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id PAA10459 for <>; Tue, 24 Sep 2002 15:52:12 -0400 (EDT)
Received: (from majordomo@localhost) by (8.11.6/8.11.3) id g8OJcmh08721 for ietf-openpgp-bks; Tue, 24 Sep 2002 12:38:48 -0700 (PDT)
Received: from ( []) by (8.11.6/8.11.3) with ESMTP id g8OJclv08717 for <>; Tue, 24 Sep 2002 12:38:47 -0700 (PDT)
Received: (from dshaw@localhost) by (8.11.6/8.11.6) id g8OJcjM21245 for; Tue, 24 Sep 2002 15:38:45 -0400
Date: Tue, 24 Sep 2002 15:38:44 -0400
From: David Shaw <>
To: OpenPGP <>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
Message-ID: <>
Mail-Followup-To: OpenPGP <>
References: <00c001c263fb$a8d70480$>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00c001c263fb$a8d70480$>
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
User-Agent: Mutt/1.5.1i
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>

On Tue, Sep 24, 2002 at 02:53:23PM -0400, Michael Young wrote:

> A moment ago, I agreed with Jon's assertion that:
> > >Key expirations are not "my" system. They're the way the OpenPGP works. If
> > I agree with Jon's analysis.  Certainly, key expirations as they
> > are defined now are rewriteable.  His example (periodically
> Sigh.  Perhaps I shouldn't have been quite so quick to agree.
> The last few drafts have included language on rewriting self-signatures,
> but I can't find any in the "original" (
> This makes it a little hard to assert that this is just "how OpenPGP works".
> BUT... this is "how GnuPG works" with respect to the act of
> rewriting, and it may just be "how PGP and GnuPG work" with
> respect to interpreting multiple expiration times.
> Bodo an David have proposed using the key-expiration[9] and
> (self-)signature-expiration[3] subpackets as "hard" and "soft"
> flavors.  One could implement Jon's "rolling expiration"
> scenarios with the self-signatures.

Whoah - I am not proposing that.  My comments were in the context of
how a potential v5 key format could work (and as a side note on how
GnuPG handles a v3 key with a v4 selfsig).  That's all.  As I see it,
without an expiration date *in the key packet*, there is no true
"hard" expiration date.  I agree with Jon's analysis.

> Alas, neither PGP(6.5) nor GnuPG(1.0.6) generates a signature-
> expiration[3] subpacket.  GnuPG's expiration-changing function
> operates on the key-expiration[9] subpacket.

GnuPG 1.0.6 is fairly old now.  More recent versions allow the
(determined) user to generate themselves an expiring self-signature
(via subpacket 3).  When that self-signature expires, the user ID it
binds (not the key) becomes invalid.  Of course, you then end up with
a key with no valid user IDs.  This is as per "Notes on
Self-Signatures" in bis-06.


   David Shaw  |  |  WWW
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson