-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, Mar 22, 2003 at 02:07:02AM +0100, Bodo Moeller wrote:
David Shaw <dshaw(_at_)jabberwocky(_dot_)com>:
On Thu, Mar 06, 2003 at 03:53:30PM +0100, Bodo Moeller wrote:
What about appending a new section after 5.2.3.3 as follows to ensure
that there is a way to express key expiry such that keys cannot be
un-expired by attackers later (see the threads at
http://www.imc.org/ietf-openpgp/mail-archive/msg02374.html
http://www.imc.org/ietf-openpgp/mail-archive/msg02848.html
http://www.imc.org/ietf-openpgp/mail-archive/msg03693.html
and finally
http://www.imc.org/ietf-openpgp/mail-archive/msg04220.html
I've read all this, and I believe I understand what you are trying to
do: get back the "hard" expiration date that v3 keys had, rather than
the "soft" expiration date of v4 keys. However, while the suggested
fix results in something closer to a hard expiration date, it is not
as hard as the original v3 expiration date since the expiration date
still vulnerable to manipulation if an attacker can influence the key
distribution channel. [...]
Can you elaborate? With my proposal, to set a "hard" expiration date,
you include it in the certification self-signatures. Thus an
adversary who wants to remove the expiration date has to remove the
self-signatures, rendering the key invalid (at least for software that
rejects keys without self-signatures -- possibly this is a requirement
that is missing in the specification, but this problem would affect V3
keys as well).
I think I wasn't clear enough. An attacker that gets the secret key
for an expired v3 key cannot un-expire that key without causing all of
the certifications on this key to become invalid. However, with your
proposal for handling expiration on v4 keys, this same attacker - if
she can control the key distribution channel - *can* perform this
attack. All she needs to do is issue a new certification
self-signature without the key expiration subpacket, remove the old
self-signature, and distribute this new key.
I do agree that your proposal is "harder" than the current v4
expiration system, but at the same time, it is not as hard as the v3
system where any expiration tampering breaks every single
certification.
This is why I was wondering why you didn't propose a v5 key that put a
hard expiration date back into the key packet itself. That is a truly
hard expiration date as it cannot be tampered with even if the
attacker can influence the key distribution channel. Any tampering
would break every certification on the key (whether self-sigs or
otherwise).
David
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2rc1 (GNU/Linux)
Comment: http://www.jabberwocky.com/david/keys.asc
iD8DBQE+fIww4mZch0nhy8kRAlsHAJ4w7AF4LXq0w8Urw1K8w0GUtWFEwgCbBy2c
A58K907wf/ltB+RUPqYBP00=
=i0gd
-----END PGP SIGNATURE-----