At 12:55 PM -0700 7/8/1999, Bodo Moeller said:
BTW, was this ever discussed:
It should be mentioned (in the Security Considerations section, if not
in the specification text) that, when signing a certificate for a
signing key that has a key expiration time set in a self-signature, it
is unwise not to include a signature expiration time subpacket
defining a validity period that extends no longer into the future than
the key's validity period.
If this rule is not obeyed when certifying keys, then the key validity
period is effectively just a key usage period. There's no difference
as far as encryption is concerned, but for signing keys the key
expiration time sub-packet would be rendered all but meaningless: you
could just as well simply stop using the key without declaring so in
advance. The big problem is that if attackers learn the secret part
of the "expired" signing key, they can easily generate a new
self-signature with an adjusted validity period unless the original
validity period is duplicated in the key certificates. (This
potential flaw does not apply to keys in version 3 public key packets,
because they have the validity period defined in the key packet
itself, not in a self-signature packet, which means that it is
automatically covered by all certificates.)
No, this has never been discussed.
I think you have a good point, but I also disagree at least a little.
One of the things that I'd like to see software do operationally is
something I call "rolling validity." I'd like to see keys have a relatively
short life that keeps getting pushed out, by being re-validated.
As an example, I might have my validity period be three months. Perhaps
then, today my OpenPGP software tells me that come August 1, my self-sig
will expire. Maybe I should re-validate now. I concur, retype my
passphrase, and the new expiration time is November. It sends my updated
key to any servers I need it to go to.
I think one of the major problems we have is lost keys dangling around
forever. If software used something like rolling validity, lost keys would
time out, people who don't use their keys much would be noticible.
Presently, since the UI doesn't let you unexpire a key, no one makes keys
with expiry, except for certain, limited uses (for example, where I work we
just put an expiration on a summer intern's key). But today a key with an
expiry is the exception. I'd rather see it be the rule. For it to be the
rule, there can't be a huge penalty for doing so.
Jon