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

"Michael Young" <> Tue, 24 September 2002 18:03 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id OAA07615 for <>; Tue, 24 Sep 2002 14:03:38 -0400 (EDT)
Received: (from majordomo@localhost) by (8.11.6/8.11.3) id g8OHjvx01627 for ietf-openpgp-bks; Tue, 24 Sep 2002 10:45:57 -0700 (PDT)
Received: from ( []) by (8.11.6/8.11.3) with ESMTP id g8OHjuv01623 for <>; Tue, 24 Sep 2002 10:45:56 -0700 (PDT)
Received: from ( []) by (AIX4.3/UCB 8.7/8.7) with ESMTP id NAA27454 for <>; Tue, 24 Sep 2002 13:32:27 -0400 (EDT)
Received: from mwyoung ( []) by (8.8.0/8.8.0) with SMTP id NAA22492 for <>; Tue, 24 Sep 2002 13:45:49 -0400 (EDT)
Message-ID: <003d01c263f1$f92f73e0$>
From: "Michael Young" <>
To: "OpenPGP" <>
References: <>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
Date: Tue, 24 Sep 2002 13:44:02 -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
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>
Content-Transfer-Encoding: 7bit

Hash: SHA1

>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
pushing the expiration out to account for possible LOSS) is
quite reasonable.  It MIGHT HAVE been reasonable to include
a form of irrevocable expiration that acts as an automatic
revocation (possibly in addition to the revocable, advisory
kind), but that's just not the way it works now.

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.

> We've even had discussions here for years about re-writing
> self-sigs and what you should do, and how you should interpret them, and
> what happens when you have things like a designated revoker.

This is another digression, but...

While I strongly believe in the ability to rewrite self-signatures, I
wouldn't go as far as to require that *all* subpackets be treated the
same in this regard.  For some, it might make sense for new values to
replace the old (preferences); here, I have argued that the old
self-signature should be revoked, but that didn't seem to catch on.
For some, new values may be additive; revocation keys have this
flavor -- they make no sense if they can be removed.
My point is simply that we shouldn't take the rewriting behavior
for key expiration as a general principle, or vice versa.

Version: PGP Personal Privacy 6.5.3