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

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.

cheers
-- vbi

-- 
NOTE: my email addresses in usenet postings change frequently!

signature.asc
Description: This is a digitally signed message part