ietf-openpgp
[Top] [All Lists]

Re: Problems with v4 key packet format

2005-09-21 06:33:19

On Wed, Sep 21, 2005 at 01:28:27PM +0100, Ben Laurie wrote:

2. No explicit count of MPIs constituting the key material (both public and
private).

This information can only be inferred from the algorithm specifier, meaning
that any implementation that wants to perform key management must have some
rudimentary knowledge about all public key algorithms. This, in turn,
hampers forward-compatibility.

This appears to me to be incorrect - an implementation that didn't know 
the algorithm could still deduce the number of MPIs by parsing the 
packet until it is exhausted. This would mean introducing a requirement 
that all public key parameters were MPIs, of course.

You could also do what GnuPG does - if it doesn't know the algorithm
it just reads the entire list of MPIs (or anything else in the packet)
into an opaque buffer.  I suppose it could figure out the MPIs, but
there seems to be little point since either way, the key is not usable
without support for the algorithm.  I suppose if the implementation
stored keys in a backend that needed to know the individual key
parameters that would be different.

3. Key fingerprint depends on data unrelated to the actual key (namely:
creation date).

This prevents solutions when signature keys are generated on the fly (e.g.
directly from a passphrase), as the key creation (or, in this case, key
registration) date is not available at the time of signing, thus making it
impossible to put am unambiguous reference to the public key into the
signature.

Not impossible, but I'll agree, crufty. One could use a fixed creation date.

Some people want to include things in the key fingerprint and some
don't.  There are good reasons for both, so I favor v5 keys with
optional subpackets like v4 signatures.  Within reason, it's a "make
everyone happy" solution.

David