[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
-----BEGIN PGP SIGNED MESSAGE-----
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 and
(self-)signature-expiration 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 subpacket. GnuPG's expiration-changing function
operates on the key-expiration 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.
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3
-----END PGP SIGNATURE-----