On Thu, Sep 22, 2005 at 01:03:20AM +0200, Daniel A. Nagy wrote:
On Wed, Sep 21, 2005 at 05:55:03PM -0400, David Shaw wrote:
The thing is, I can't really decide if that is a threat or a
feature...
In such cases isn't the best policy to let the users and/or implementers
decide
for themselves? How about having hashed and unhashed subpackets just like in
v4 signatures, where all are subject to signatures but only the hashed ones
are included in the fingerprint?
I think this might cause some serious user confusion. With both types
of subpackets, plus the existing v4 signature subpackets, we would
have three different ways to specify expiration, each with a slightly
different meaning:
key-subpacket-in-fingerprint:
hard expiration date. All other expiration dates can only be
extended to this point. Changing it changes the fingerprint and
key ID.
key-subpacket-in-signature:
soft expiration date. Changing it invalidates all signatures, but
does not change the fingerprint/key ID.
regular-old-selfsig:
very soft expiration date. Can be changed at any time with no
impact on anything but the expiration date.
Then we have various combinations of the above...
David