ietf-openpgp
[Top] [All Lists]

Re: Rip Van Winkle awakes: meeting in Oslo?

1999-07-08 13:02:15
"John  W. Noerenberg" <jwn2(_at_)qualcomm(_dot_)com>:

3. Numerous revisions/enhancements/improvements to rfc2440 have been proposed
Jon Callas enumerated several items back in April.  Some of them have 
been discussed on the list recently (notably V5 sigs).  Is there 
interest in any of the others?

BTW, was this ever discussed:

5.2.3. Version 4 Signature Packet Format

5.2.3.5. Key expiration time

   (4 octet time field)

   The validity period of the key.  This is the number of seconds after
   the key creation time that the key expires.  If this is not present
   or has a value of zero, the key never expires. This is found only on
   a self-signature.

5.2.3.9. Signature expiration time

   (4 octet time field)

   The validity period of the signature.  This is the number of seconds
   after the signature creation time that the signature expires. If this
   is not present or has a value of zero, it never expires.

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.)

<Prev in Thread] Current Thread [Next in Thread>