Re: V5 key packet format requirements

[Ben Laurie <[e-mail]>]

Daniel A. Nagy wrote:
> 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).

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

> 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.

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.

> 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!

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

Aren't they patented?

> 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.

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