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
Attachment:
signature.asc
Description: Digital signature