[Top] [All Lists]

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

2002-09-24 11:55:41

Hash: SHA1

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.

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.

Version: PGP Personal Privacy 6.5.3