At 02:07 AM 3/22/2003 +0100, Bodo Moeller wrote:
... 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 *something* -- preferably along the lines of a "MUST" -- needs to be
added about software rejecting invalid keys.
PGP 8.0 has the following interesting "feature": if you simply render the
self-signature on a V4 key invalid (say by modifying the embedded hash value),
PGP8 *quietly* ignores that signature block (along with its expiration date)
when importing the key and allows it to be used like any other (unsigned) key.
So, if I create a key for myself with a fixed expiration date -- anticipating
the public revelation of my private key shortly after that date -- an attacker
can thwart my intentions by simply changing a single byte in the key. No PGP8
user would ever know the key had been tampered with... or that it was supposed
to expire. After all, the "fingerprint" on the key is still valid, so even
if a
user checks it against the value published on my website, they'd never detect
the attack! (I don't think there is a solution, since the attacker can also
simply strip off the signature block. I guess I'm really complaining that
OpenPGP keys do not behave like X.509 certificates: if the signature block
contains a critical attribute like an expiration date, stripping it *should*
render the key invalid AND unusable... or at least generate a warning!)
In any case, since PGP8's strange behavior doesn't appear to violate anything
in the latest draft, I can't help feeling that
draft-ietf-openpgp-rfc2440bis-07's
claim to "discuss implementation issues necessary to avoid security flaws" is
rather empty.
-mjm