David Shaw <dshaw(_at_)jabberwocky(_dot_)com>:
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 [...]
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.
Er, yes, actually I am aware of this, I don't know what I was thinking
when I wrote my previous message. -- The attacker could not actually
"un-expire" an expired key (because that key would not have any valid
certifications at all once it has expired assuming that all
certifications follow the suggested procedure); but if an attacker
obtains the secret key for a key that has not yet expired, he can
increase key lifetime beyond the intended expiry date by issuing new
self-signatures. (In consequence, new certifications by others could
last longer than intended by the legitimate key owner.) So while key
expiration would be final, expiration dates would not be as hard as
with the V3 format.
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).
I definitely would suggest to include provisions for hard expiration
dates in the V5 format when it is defined. My proposal does not do
this because I wanted to show what can be done without redefining the
format in an incompatible way.
--
Bodo Möller <moeller(_at_)cdc(_dot_)informatik(_dot_)tu-darmstadt(_dot_)de>
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