Subject: Re: Behavior of implementations regarding certain key material

From: [email-masked]
Date: Wed, 31 May 2000 10:13:00 -0700

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

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 31 May 2000 23:25:49 +0200

On Wed, May 31, 2000 at 10:13:00AM -0700, [email-masked] wrote:

>>                      [...]  Thus, if someone breaks or steals an

> The first problem applies to key revocations as well.

Only if you you accept keys without a self-signature.
GnuPG treats self-signatures as mandatory, which avoids this attack.
(As far as self-signatures are concerned -- key revocations are
obviously not mandatory :-)

>                                                        With a good key

Software could accept such life-extending signatures if they are
received *while the key is still valid* (according to an earlier
self-signature) -- later on, it could be argued that new
self-signatures *must* be ignored because the key-owner told you so
by having his signature key expire.
(In case trusted timestamps by whatever means are available,
date of receipt could be replaced by the timestamp date.)

Note that key-expiration sub-packets as defined in RFC 2440 are still
very useful for sub-keys: During the lifetime of your signature key,
you could publish new encryption keys with short lifetime and with
up-to-date cipher preferences (according to your current choice of
software, availability of hardware accelerators, the state of the art
of cryptography research, and so on), or could re-sign an existing
encryption key with longer lifetime and updated cipher preferences.
So it's not fully true that the original goal of putting expirations
into the self-signatures is missed.

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

Yes, but it needs stronger assumptions -- you rely on what you call
"a good key distribution infrastracture", i.e. you assume that the
attacker cannot influence the infrastructure to hide existing
signatures from you.

A more prudent approach is to say that the inferred semantics should
be monotonous in the set of signatures that one has seen; that is, to
never base trust in something on the fact that you have *not* seen
certain signatures.  I am fully aware that this does not work for key
revocations, but that's because they are a last resort -- and if you
revoke a key because it has been compromised, then probably you won't
just post the revocation to your favorite key server, but will also
mail it directly to the folks you're communicating with; obviously
such effort cannot usually be expected when handling ordinary key
certificates.  (OK, the S/MIME people do that all the time by
effectively appending the equivalent of a "key ring" to their
messages, but I hope you get the idea ...)

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036