Re: Hard expiration dates (was: I-D ACTION:draft-ietf-openpgp-rfc2440bis-07.txt)

[David Shaw <dshaw@xxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Mar 22, 2003 at 02:07:02AM +0100, Bodo Moeller wrote:
> 
> David Shaw <dshaw@xxxxxxxxxxxxxxx>:
> > 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-----