[Top] [All Lists]

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

2002-09-24 12:38:48

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  |  dshaw(_at_)jabberwocky(_dot_)com  |  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