Re: More on key expiration policy (Re: draft-ietf-openpgp-rfc2440bis-06.txt)

Len Sassaman <> Mon, 23 September 2002 23:51 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id TAA29614 for <>; Mon, 23 Sep 2002 19:51:41 -0400 (EDT)
Received: (from majordomo@localhost) by (8.11.6/8.11.3) id g8NNiOY18521 for ietf-openpgp-bks; Mon, 23 Sep 2002 16:44:24 -0700 (PDT)
Received: from ( []) by (8.11.6/8.11.3) with ESMTP id g8NNiMv18517 for <>; Mon, 23 Sep 2002 16:44:22 -0700 (PDT)
Received: by (Postfix, from userid 500) id 1FEBC45028; Mon, 23 Sep 2002 16:44:24 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0819C48023; Mon, 23 Sep 2002 16:44:23 -0700 (PDT)
Date: Mon, 23 Sep 2002 16:44:23 -0700 (PDT)
From: Len Sassaman <>
X-Sender: <>
To: Michael Young <>
Cc: OpenPGP <>
Subject: Re: More on key expiration policy (Re: draft-ietf-openpgp-rfc2440bis-06.txt)
In-Reply-To: <00d101c2634b$1b4e2b80$>
Message-ID: <>
X-AIM: Elom777
X-icq: 10735603
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>

On Mon, 23 Sep 2002, Michael Young wrote:

> Bodo originally suggested that clients abide by expiration times when
> creating new certifications.  That alone may not prevent a compromised
> key from being misused.  Yes, it would work for certifications prior
> to the compromise, and for new ones where the signer gets the key
> *directly* from the owner, but that still doesn't cover all cases.

Wasn't the original suggestion that keys expire at the earliest expiration
time, and later expiration dates be ignored? That would address the

Jon's request is also solved, too, by using signature expirations as long
as keys without self-signatures are treated as invalid keys.

> The problem is that fingerprints don't include the expiration time.

I agree this is a problem.

> This may be another fair argument for allowing rewriting.  If you
> really wanted irrevocable expiration times, you'd want to hash them
> into the fingerprint material, but it's way too late for that.

I think there are several things that are put into self-sig rather than
the key that shouldn't be. I also think that having the "signing only" and
"encrypt only" flags in the self sig, and not in the key, is also a
mistake. (I feel guilty about this, since I think I was the one who
suggested PGP 7 do things as the spec recommends. I now think that's
broken.) :(

Attributes of the key that intended to be permanent really should be so.

> > The question I see is this: are key expiration dates a "mandate" or a
> > "suggestion" to third parties by the key owner?
> More precisely, are expiration times rewriteable?
> I'm afraid that the answer has to be YES.  The specification has
> clearly said so for a while now, and at least one implementation
> (GnuPG) offers this capability.  If we change the rules now,
> anyone who has taken advantage of it (or set a short expiration
> time with the expectation that they can change it) will be
> seriously disappointed.

In that case, expiration dates don't seem to mean what everyone thinks
they mean.