Re: Hard expiration dates (was: I-D ACTION:draft-ietf-openpgp-rfc2440bis

On Sat, Mar 22, 2003 at 01:23:15PM +0100, Adrian 'Dagurashibanipal' von Bidder 
wrote:
> On Sat, 2003-03-22 at 02:07, Bodo Moeller wrote:
>
> > > 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).
> Not having read all the references, I could be wrong. But IIRC the
> really hard thing about v3 expiration date was that changing the
> expiration date would also change the key fingerprint (and keyid?). So,
> even when the adversary comes to possess the secret key he can't
> unexpire the key.
V3 key fingerprints are calculated differently than v4, so the
V3 fingerprint would not change.  However, changing the expiration
date on a v3 key does change the hash of the key which causes all
certifications on the key to break.  A completely uncertified key is
of little use to an attacker.

David

pgpfPMzDGU8Qa.pgp
Description: PGP signature