ietf-openpgp
[Top] [All Lists]

Re: Behavior of implementations regarding certain key material

2000-05-31 10:04:32
Bodo Moeller writes:
In the old PGP key format, key certification covers the expiration
time, and all is well. (The validity period [key creation time and key
expiration time] is part of the version 3 public key packet.)
However, in the current OpenPGP key format, the key expiration time is
covered only by self-signatures.  (A version 4 public key packet
cannot specify a validity period.  The key validity period is in the
signature packet instead.)  Thus, if someone breaks or steals an
expired OpenPGP key, they can renew it, and the old certificates will
remain valid for the key with extended validity period or unlimited
validity.

I agree that this is a problem.  In retrospect I wish we had done key
expirations differently.

There are two possible attacks: one is to strip away the self signature
entirely, making it appear that the key has no expiration.  The other
is to issue a new self signature with a longer expiration.

The first problem applies to key revocations as well.  With a good key
distribution infrastructure this should not be much of an issue.  The
second problem is specific to expirations.

A workaround is to adopt the convention that if a key has multiple
expirations, the earliest one applies.  This prevents the "zombie key",
where the attacker attempts to bring a dead key back to life.  However it
also prevents what I think was the original goal in putting expirations
into self-sigs, which was to allow key holders to extend the life of
their keys if they choose.

Fix: Always include a signature expiration time when certifying a key
that has a key expiration date in its self-signature; the time must be
chosen such that the certificate's validity does not extend further
into the future than the key's validity.

That's a good idea, whether or not my proposal above was adopted.

The bottom line is that if you don't want to rely on signatures by
expired keys, then you cannot rely on any certificates that don't
contain a signature expiration time (unless the certified key
is in a version 3 public key packet).

I think that my proposal would provide another way of addressing this.

Hal