Subject: V5 key packet format requirements

From: [email-masked] (Daniel A. Nagy)
Date: Thu, 2 Feb 2006 17:07:13 +0100

I know that this has been discussed earlier, but I think it is important to
weed out and summarize the requirements for the upcoming V5 key packet format.

Public key packet format

1. Exclude creation date from fingerprint and key ID hash computation (and
maybe from the key packet, too -- it belongs to the self-signature). This
would mean that the key fingerprint and ID depend only on the actual key
(key material + algorithm).

Private key packet format

1. Change wording of standard to indicate that this is intended to be merely
an export-import format. Implementations can obtain private keys any way
they see fit.

2. Scrap encrypted private keys. We already have a symmetrically encrypted
container format with sufficient integrity protection, so there is no reason
to maintain another one. Just put the unencrypted private key packet into
that container, if you need encryption. This will reduce the number of things
to worry about and make the security of OpenPGP easier to assess and
maintain.

3. Support for multiprime RSA keys (as in PKCS#1 v2.1).

4. Support for exporting and importing subkeys.

I think, the above are all legitimate needs that should be addressed in the
new packet format. I cannot think of more.

Comments?

-- 
Daniel

---

From: Ben Laurie <[email-masked]>
Date: Fri, 03 Feb 2006 11:53:33 +0000

> (key material + algorithm).

This could be confusing - documents that were signed with a key
specified like this could retroactively find themselves predating the key.

> an export-import format. Implementations can obtain private keys any way

Also, from memory, private keys include stuff that can be calculated (or
is it that they don't include stuff that's useful to have
precalculated?). In any case, it would be good to know what's optional.

> to worry about and make the security of OpenPGP easier to assess and

Yes, please!

> 3. Support for multiprime RSA keys (as in PKCS#1 v2.1).

Aren't they patented?

> new packet format. I cannot think of more.

Support for PFS.

-- 
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: Ben Laurie <[email-masked]>
Date: Fri, 03 Feb 2006 12:51:36 +0000

Adam Back wrote:
> On Fri, Feb 03, 2006 at 11:53:33AM +0000, Ben Laurie wrote:
> 
>>> 2. Scrap encrypted private keys. We already have a symmetrically
>>> encrypted container format with sufficient integrity protection, so
>>> there is no reason to maintain another one. Just put the
>>> unencrypted private key packet into that container, if you need
>>> encryption. This will reduce the number of things to worry about
>>> and make the security of OpenPGP easier to assess and maintain.
>> Yes, please!
> 
> What if you want different password on different keys?
> 
> (Think eg long term signing key vs short term signing key -- no point
> having separate signing keys unless have possibility to use different
> password.)

Eh? You can have 1 symmetric encrypted packet per key, they don't have
to share one.

---

From: Edwin Woudt <[email-masked]>
Date: Fri, 03 Feb 2006 14:05:34 +0100

> (key material + algorithm).

IMHO, things that have nothing to do with the user ID should not be in a 
self-signature, but in a direct key signature (type 0x1F) instead.

> container format with sufficient integrity protection, so there is no
> reason to maintain another one. Just put the unencrypted private key
> packet into that container, if you need encryption. This will reduce the
> number of things to worry about and make the security of OpenPGP easier
> to assess and maintain.

Agreed.

> 4. Support for exporting and importing subkeys.

Why is this needed? Isn't this possible already using the current (V4) 
packet formats?

-- 
Edwin

---

From: [email-masked] (Daniel A. Nagy)
Date: Fri, 3 Feb 2006 14:32:03 +0100

> self-signature, but in a direct key signature (type 0x1F) instead.

That's a self-signature, too (just not a key-uid binding one). But I agree
that signatures on keys are less popular with implementations than they
should be. OTOH, this is not directly related to the key packet format.
 
> Why is this needed? Isn't this possible already using the current (V4) 

It is possible, but in many different ways. Implementations are generally
not interoperable. This stuff must be standardized, IMHO.

-- 
Daniel

---

From: Edwin Woudt <[email-masked]>
Date: Fri, 03 Feb 2006 16:58:34 +0100

> But I agree

The introduction of V5 would be a good moment to remedy this situation.

-- 
Edwin

---

From: Ian G <[email-masked]>
Date: Fri, 03 Feb 2006 17:43:24 +0100

> specified like this could retroactively find themselves predating the key.

Why is this important?  The date on the key is
just "there" and isn't of such strength that it
should be stressed overly much.

The dates of importance are the date of signing
(which should be in the signature) and the date
of attesting some meaning to the key for the
purpose of signing documents.  The date of the
key creation would appear to be just some artifact
of the tech.

(And for some things like password-generated keys,
would appear to be a non-date.)

>>to worry about and make the security of OpenPGP easier to assess and

Yay!  Less is always better.

iang

---

From: [email-masked] (Daniel A. Nagy)
Date: Fri, 3 Feb 2006 13:34:48 +0100

> having separate signing keys unless have possibility to use different

Then you put the two key packets in two different containers with different
passphrases. And again, keep in mind that this is primarily and
export-import format.

-- 
Daniel

---

From: Adam Back <[email-masked]>
Date: Fri, 3 Feb 2006 07:25:26 -0500

Adam

---

From: Konrad Rosenbaum <[email-masked]>
Date: Fri, 3 Feb 2006 19:09:06 +0100

> should be stressed overly much.

Consequently one would also need to scrap the logic that a signature is 
invalid if it predates the key (that's somewhere in RFC2440).

Why not: hash the _complete_ public key packet _as_is_ without any 
modifications? 

The computational load of hashing a few bytes more and of slicing them first 
should be about identical.

It is very easy to implement (read as: less potential security holes through 
programming mistakes and higher interoperability).

It is much more resistant against upcoming attacks than a selective model.

	Konrad

---

From: [email-masked] (Daniel A. Nagy)
Date: Fri, 3 Feb 2006 19:51:19 +0100

> invalid if it predates the key (that's somewhere in RFC2440).

I disagree. I'm merely advocating moving the key creation time into the self
signature, which is the only obstacle to forgery anyway:

If you give me a signed document that predates the key along with that key,
I can change the date in the key, re-calculate the hash, change the
reference to the key in the signature and voila, I have a valid signature,
without access to any private info. The only thing stopping me is the
self-signature on the key, which also hashes the key creation date. So, that
self-signature is the real cryptographic protection, not the reference in the
document signature. Thus, one does not reduce security a bit by moving the key
creation date into the self-signature. That is where it belongs.
 
> It is much more resistant against upcoming attacks than a selective model.

I agree. This is why I am calling for throwing the key creation date out
of the key packet. The key packet should only contain an algorithm identifier,
the key material and possibly deterministic functions thereof.

-- 
Daniel

---

From: Jon Callas <[email-masked]>
Date: Tue, 7 Feb 2006 16:02:00 -0800

> weed out and summarize the requirements for the upcoming V5 key  

[...]

> Comments?

Yes, that while I agree with most if not all of what you suggest,  
that this is post-2440bis. Hold those thoughts until we get this  
document done.

	Jon