-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
-----Original Message-----
From: owner-ietf-openpgp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openpgp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Bodo
Moeller
Sent: Monday, September 23, 2002 9:01 AM
To: Derek Atkins
Cc: Jon Callas; OpenPGP
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
On Mon, Sep 23, 2002 at 09:55:19AM -0400, Derek Atkins wrote:
Yes he can -- this is exactly the problem [1] that I want to solve
with my suggested change to the specification. The way Jon wants
to use key expiration, the bad guy can keep the key alive
indefinitely. I call this a protocol failure, he calls it a
feature.
I've been following this thread somewhat, and I have the following
suggestion:
IIRC, key expirations are stored in the self-signature. So, a PGP
client could take all of the valid self-signatures, and compare
expiration dates. The oldest one would be honored.
This means that you cannot extend the key expiration. However, if you
don't want an attacker to be able to extend the key expiration if he
or she has the private key, this also means that the legitimate owner
of key cannot be allowed to extend the expiration date.
There is another large flaw with this plan. An attacker would only
need to revoke the self-signature, thus making it invalid. So, for
the meaning of this discussion, a "valid self-signature" would be one
that is correct in cryptographic terms, but revocations are ignored.
Deleting the other self-signatures would work, but since keyservers
only add to a key, synchronization with a keyserver could defeat this
attack method. However, if we ever implement the "no-modify" flag,
there is no reason the attacker (with possession of the private key)
couldn't send the key to the keyserver with the other signatures
deleted and the "no-modify" flag set. So, this may require that
keyservers maintain all self-signatures, even if the "no-modify" flag
is set.
So, to recap, if you ignore my implementation notes, the following
choice needs to be made:
1. Is extending a key expiration date by a key's owner a REQUIRED
action. If not, this is feasible. If so, I can't think of a way to do
it.
Richard Laager
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4
iQA/AwUBPY9T3231OrleHxvOEQII8gCfWwIaXS/eLAy7hnouhI5j2ZXXobIAmgLJ
DkNjYcTIJ/Yb4Gz6QdJ3v5DQ
=cJQr
-----END PGP SIGNATURE-----