Subject: Re: Problems with v4 key packet format

From: [email-masked] ("Hal Finney")
Date: Wed, 21 Sep 2005 14:26:13 -0700 (PDT)

Daniel Nagy writes:
> On Wed, Sep 21, 2005 at 09:52:33AM -0700, "Hal Finney" wrote:
> > I would like to see immutable material put there.  One thing that bothers
> > me in the current V4 is that the key's expiration date can be changed by
> > updating the self-signature.  Suppose your key has expired and you don't
> > use it any more.  As a result perhaps you don't protect it that well.
> > If someone gets hold of the private part, they can issue a new self-sig
> > with a new expiration date and bring this dead key back to life.  It would
> > be better if a dead key would stay dead.  Expiration date and creation
> > date would be better placed in the key packet, IMO (as they were with
> > V3 keys).
>
> Careful! If this information is not part of the fingerprint/keyID it can
> still be changed by updating the self-signature, no matter whether it's in
> thte signature packet or in the key packet.

Not exactly, the self-signature would not (by convention) override the
information in the key subpackets.  So just issuing a new self-signature
would not help.

What could happen is that someone who got hold of the private material
could create a new key packet with the same keyid/fingerprint but with
a different expiration date.  But(!) the new key would not inherit the
signatures on the old key.  That is what I was thinking of as important.
It would not be valid, it would not be part of the Web of Trust.
The idea is that key signatures would cover all of the subpackets,
even though fingerprints do not.

> David's idea with sub-packets should be implemented in such a way that
> hashed sub-packets are part of the fingerprint. Maybe, we don't even need
> unhashed sub-packets.
>
> If you're importing a foreign key or generating one on the fly, you don't
> put subpackets into the key that cannot be determined next time you use the
> same source to get the key. A flag in a subpacket indicating where the key
> comes from might be useful, though.

This is a good point, I'll have to think about it.  I'm still not
sure that covering this material with key fingerprints and keyids is
the right thing to do.  What would the security threats be from being
able to bring a key back to life with the same fingerprint and keyid,
but without any signatures on it being valid?

Hal Finney

---

From: David Shaw <[email-masked]>
Date: Wed, 21 Sep 2005 17:55:03 -0400

> but without any signatures on it being valid?

My original idea with subpackets was that they would be part of the
fingerprint, and changing a subpacket was akin to making a whole new
key as the fingerprint and key ID (though not the key material) would
change.  I see some advantages of what you are discussing.  It would
(somewhat) allow someone to violate a hard expiration date on their
key: make the key, get signatures, and then when the key expires, just
remake the key.  Essentially you can buy an extension on your "hard"
expiration time at the cost of losing all of your signatures.

The thing is, I can't really decide if that is a threat or a
feature...

David

---

From: [email-masked] (Daniel A. Nagy)
Date: Thu, 22 Sep 2005 01:00:43 +0200

> information in the key subpackets.  So just issuing a new self-signature

That's not what I meant. If the self-signanture is the only integrity
protection measure, then someone in possession of the private part of the
key can alter the expiration date in the key packet just as he can alter it
in the signature subpacket. If it's hashed with the key ID, changing it
would also change the key ID, ergo resulting in a different key.
 
> signatures on the old key.

That's correct.

>  That is what I was thinking of as important.

And what about keys that are not part of WoT? In the present standard, I can
trust a key not only because someone I trust has signed it, but also because
I know the fingerprint. Should we break that?

> the right thing to do.

Me neither, but the more I think about it, the more I am leaning towards
giving the choice to the user by having hashed and unhashed subpackets, both
of which are signed, but only the hashed ones being included in the
fingerprint. But I'll have to think more about it myself.

> What would the security threats be from being

Well, it depends on the applicatiton and the user's trust model. What I like
most about OpenPGP is the flexibility of the trust model. Ignoring the WoT
is certainly an option I would like to have.

-- 
Daniel

---

From: [email-masked] (Daniel A. Nagy)
Date: Thu, 22 Sep 2005 01:03:20 +0200

> The thing is, I can't really decide if that is a threat or a

In such cases isn't the best policy to let the users and/or implementers decide
for themselves? How about having hashed and unhashed subpackets just like in
v4 signatures, where all are subject to signatures but only the hashed ones
are included in the fingerprint?

-- 
Daniel

---

From: David Shaw <[email-masked]>
Date: Wed, 21 Sep 2005 20:47:58 -0400

> are included in the fingerprint?

I think this might cause some serious user confusion.  With both types
of subpackets, plus the existing v4 signature subpackets, we would
have three different ways to specify expiration, each with a slightly
different meaning:

key-subpacket-in-fingerprint:

    hard expiration date.  All other expiration dates can only be
    extended to this point.  Changing it changes the fingerprint and
    key ID.

key-subpacket-in-signature:

    soft expiration date.  Changing it invalidates all signatures, but
    does not change the fingerprint/key ID.

regular-old-selfsig:

    very soft expiration date.  Can be changed at any time with no
    impact on anything but the expiration date.

Then we have various combinations of the above...

David

---

From: Konrad Rosenbaum <[email-masked]>
Date: Thu, 22 Sep 2005 20:47:05 +0200

> but without any signatures on it being valid?

It becomes a threat once you get hold of the private key (through some 
accident, a data leak, whatever) because then you can also issue new 
self-signatures.

I see two possibilities to limit the damage: 

a) changing the expiration also changes the fingerprint, so the key does no 
longer match whatever users have in their keyring and would basically be a 
new key. 

b) changing the expiration breaks ALL signatures (not only self-sig) on the 
key. (Actually b must be implemented as well, when a is implemented.)

On the other hand: expiration dates are a very weak measure against key 
abuse (they only limit the damage), un-revocable revocation sigs seem much 
more effective to me.

	Konrad

---

From: David Shaw <[email-masked]>
Date: Thu, 22 Sep 2005 15:06:48 -0400

> key. (Actually b must be implemented as well, when a is implemented.)

If I understand what Hal was proposing, then b is already true.
Self-sigs aren't treated any differently than any other certification
signature.

> abuse (they only limit the damage), un-revocable revocation sigs seem much 

True, but an unrevocable revocation signature can be stripped off the
key, so it becomes a key distribution problem.  Expiration dates are
naturally carried along with the key.

David

---

From: Ben Laurie <[email-masked]>
Date: Fri, 23 Sep 2005 11:35:42 +0100

> The thing is, I can't really decide if that is a threat or a

You can already do this by signing the new version of the key with the 
old version of the key - same keypair, so messages to either will work, 
and signatures made by either key will still check - but different IDs 
and signatures on the keys.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: David Shaw <[email-masked]>
Date: Fri, 23 Sep 2005 07:46:43 -0400

> and signatures on the keys.

Absolutely, but from the trust perspective (at least using the web of
trust), this second key is one further "hop" away from the one that
was signed.  It becomes the same situation as if someone generated a
brand new key without doing any trickery by keeping the same key
material and just signed it with the old one; the fact that the key
material is the same is interesting, but not really useful in practice
since the (changed) key ID is used to locate it in a keyring when
verifying a signature or handling a PKESK.

David