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

From: "Michael Young" <[email-masked]>
Date: Tue, 24 Sep 2002 14:53:23 -0400

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" (http://www.ietf.org/rfc/rfc2440.txt).
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.

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.

When presented with two key-expiration versions, GnuPG appears to
accept the update (and throws away the old signature?).  PGP accepts
the update, and reports the new expiration time, but shows both
signatures.  Both PGP and GnuPG accept the new expiration time
for the purposes of encrypting; GnuPG ignores the expiration on
the main key, and accepts the one on the subkey.

I know that the specification need not be bound by quirks in
implementations, but as a practical matter, it doesn't feel
right to buck them here.  So, I come back to agreeing with Jon,
not just because the spec says so lately, but because the
implementations do, too.

---

From: David Shaw <[email-masked]>
Date: Tue, 24 Sep 2002 15:38:44 -0400

> 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.

> 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 5.2.3.3. "Notes on
Self-Signatures" in bis-06.

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "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

---

From: "Michael Young" <[email-masked]>
Date: Tue, 24 Sep 2002 16:34:40 -0400

From: "David Shaw" <[email-masked]>
> "hard" expiration date.  I agree with Jon's analysis.

OK... sorry about that.  I agree that a new key format could address this
if anyone cared enough.  (I don't.  Revocation is good enough... which
leads me to wonder how PGP/GnuPG would treat a post-dated revocation,
but that's another unnecessary digression. :-)

> GnuPG 1.0.6 is fairly old now.

It may be old in a CVS sense.  There's a lot of it out there, though...
it's in the RedHat 7.2AS and 7.3 releases, for example.  It was the
only official Windows build for a *long* time.

My point was not that GnuPG was wrong in any way, simply that some
widely installed versions wouldn't support the hard/soft distinction,
should we choose to make one now.