[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hash: SHA1

>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
pushing the expiration out to account for possible LOSS) is
quite reasonable.  It MIGHT HAVE been reasonable to include
a form of irrevocable expiration that acts as an automatic
revocation (possibly in addition to the revocable, advisory
kind), but that's just not the way it works now.

Given that this is how they work, I'd really like to see language
in the expiration time section noting that they may be rewritten,
and that as such, they do not have any revocation-like effects.
Yes, this appears elsewhere, but someone reading the spec may
not put the pieces together, and make assumptions on how
expirations work (based on other systems or their intuition).
I can draft something if you'd like.

> We've even had discussions here for years about re-writing
> self-sigs and what you should do, and how you should interpret them, and
> what happens when you have things like a designated revoker.

This is another digression, but...

While I strongly believe in the ability to rewrite self-signatures, I
wouldn't go as far as to require that *all* subpackets be treated the
same in this regard.  For some, it might make sense for new values to
replace the old (preferences); here, I have argued that the old
self-signature should be revoked, but that didn't seem to catch on.
For some, new values may be additive; revocation keys have this
flavor -- they make no sense if they can be removed.
My point is simply that we shouldn't take the rewriting behavior
for key expiration as a general principle, or vice versa.

Version: PGP Personal Privacy 6.5.3