As noted earlier, there are many problems with V4 public and private key
formats that merit the consideration of a new key format (V5). This message
is intended as a list of the problems and solutions that come to my mind in
order to initiate a discussion that would hopefully lead to a sound design
that can be standardized.
1. Private key format
1.1. Purpose
I think, it should be explicitly stated that private key packet format
is specified solely for the purpose of exporting and importing private keys.
While implementations may choose to store private keys in this format, as it
has no bearing on interoperability, it is outside the scope of the standard.
1.2. Structure
The straightforward structure of public key material followed by private key
material is fine, but the symmetrically encrypted private key material must
be ditched, in my opinion. For confidentiality protection, the entire
private key packet (including both public and private key material) must be
encapsulated in a symmetrically encrypted and integrity protected packet
(with an optional compression in between). This has several benefits: it
prevents the Klima-Rosa attack, removes the need to define and implement
symmetric encryption twice in slightly different ways, etc.
For RSA keys, facilities for the multiprime variant must be included. Public
keys with two or more prime factors should not be distinguished, though.
2. Fingerprints and Key IDs
2.1. Hashed material
I think that only the key material and the algorithm identifier should
influence the fingerprint; creation time should not, because it may not be
readily available even if the public key is. However, I like the feature of
V4 that the fingerprint is simply the hash of a canonized public key packet.
Thus, I would recommend removing creation time from the public key packet
altogether.
This approach would facilitate (partial) interoperability with hardware and
software not specifically designed for OpenPGP, as OpenPGP fingerprints and
key IDs can then be calculated for any public key, no matter where it comes
from.
2.2. String representation
Key IDs should be either decimal or octal.
There are many crypto-capable devices with numeric-only keypads (e.g.
cellphones). It would be very nice if key IDs could be conveniently typed on
such devices. As an added benefit, it would reinforce the metaphor of the
KeyID being something similar to a phone number, making it a good shot at
the middle of Zooko's triangle.
Since the key id being part of the fingerprint is a nice feature,
fingerprints may also be decimal or octal, respectively. We could also blur
the boundary between fingerprints and key ID by allowing the use of any
sufficiently long (e.g. 10 decimal or 11 octal digits) suffix of the
fingerprint as a key identifier (which is not necessarily unique, of
course).
2.3. Hash function
There should be only one, because the fingerprint must uniquely identify the
corresponding key; there shouldn't be different fingerprints for the same
key.
Increasing the length of the fingerprint reduces its usability. Again, I
would suggest the blurring of the boundary between fingerprints and key IDs,
as above. Thus, we could use some super-safe hash function (e.g. SHA-512),
but use only a sufficiently long tail for practical purposes.
Regards,
--
Daniel
signature.asc
Description: Digital signature