This is my original mail about V5 and keys with subpackets. Since V5
is being discussed now, it seems reasonable to repost.
David
----- Forwarded message from David Shaw <dshaw(_at_)jabberwocky(_dot_)com> -----
Date: Mon, 21 Feb 2005 12:11:31 -0500
From: David Shaw <dshaw(_at_)jabberwocky(_dot_)com>
To: ietf-openpgp(_at_)imc(_dot_)org
Subject: Some thoughts on a v5 key and why it shouldn't be a mess
Mail-Followup-To: ietf-openpgp(_at_)imc(_dot_)org
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
I had around 10 hours in a car this weekend, which gave me a good bit
of time to think some more about the v5 key idea.
I don't see this as a "drop everything and do v5" suggestion. It's
more of a "design v5 in 2005, because we need it a few years from
now". Attacks only get better, and if we want to be able to shrug off
a future SHA-1 break like we were able to shrug off the MD5 break, we
need to start the process. While this is prompted by the SHA-1
problems, note that NIST was already replacing SHA-1 with the SHA-2
family by 2010 for size reasons. Even if the recent SHA-1 problems
hadn't happened, I'd still think it was time to start designing a v5
key.
I don't think there needs to be a lot of fear over a version number
bump. To be sure, the change from v3 to v4 was disruptive. In one
step, the packet format, the default symmetric cipher, and the
public-key algorithm was changed. Even the concept of a key was
altered by adding subkeys. I'm not criticizing - the changes were
necessary for many reasons, but unfortunately they also split the user
base into "before" and "after", with interoperability problems between
the two groups. In some (occasionally frustrating) corners, the
change hasn't even happened yet.
I don't see the change from v4 to v5 being nearly as disruptive as the
v3 to v4 change. The straw proposal I'm putting forth here is an
incremental change over v4, large enough to be worth doing, small
enough that if the change is done carefully, it should be painless.
v4 and the proposed v5 can also quite happily co-exist without anyone
noticing or caring. Note that I'm not talking about making a v5
signature at this point.
Here is a proposed packet format for a v5 key, interspersed with
comments. Obviously, not every detail is given, but the general ideas
should be clear:
- A one-octet version number (5).
- A one-octet hash algorithm number.
This is an attempt to balance Jon's comments about 160 bits being all
that a human user can handle for a fingerprint, and the desire to not
be locked to SHA-1 in case of future trouble. Essentially you set
this value to the fingerprint hash you want to use for this key. The
value itself is hashed into the fingerprint (and signatures on the
key), so it cannot be changed once the key is generated. Is is
possible for different v5 key fingerprints to be of different lengths.
A v5 fingerprint is written "algo - colon - data", like 2:12 34 56 78
9A BC DE F0 ...(etc). The v5 keyid concept is the same as v4: the
keyid is the lower 32 or 64 bits of the fingerprint, however long it
may be.
There are some problems with this idea, not least that any
implementation that doesn't understand the hash algorithm won't be
able to use the key. It may well be better to lock this value to
SHA-256 and be done with it.
- A two-octet scalar octet count for the following subpacket
data. Note that this is the length in octets of all of the
hashed subpackets; a pointer incremented by this number will
skip over the subpackets.
- Subpacket data.
Yes, v5 keys have subpackets. It's a bit of future-proofing since it
is a lot easier to add a subpacket than it is to go to a v6 key
format. Note that there are no "unhashed" subpackets here. All
subpackets are hashed into the fingerprint, and therefore are fixed at
key generation time. The subpacket numbers do not need to be the same
as signature subpackets, but the encoding format is the same, and the
critical bit has the same meaning here as it does for signatures.
Only one subpacket comes to mind at the moment, and that is:
Expiration time
(4 octet time field)
The validity period limit of the key. This is the number of
seconds after the key creation time that the key must expire by.
If this is not present or has a value of zero, the key has no
hard expiration.
This gives a "hard" expiration time which cannot be extended, unlike
the current "soft" expiration in v4. There were a number of
disagreements over the v4 soft expirations, and while it's an
interesting discussion, at the end of the day there are good reasons
to support both. In practice, this key subpacket sets a hard limit on
the lifetime of a key, and any soft expirations can only affect the
lifetime of the key up to that hard point. No hard expiration acts
just like v4. Users can mix the two to give whatever semantics they
want.
- A four-octet number denoting the time that the key was created.
This might be better as a subpacket, but then implementers would have
to deal with the case if it was missing.
- A one-octet number denoting the public key algorithm of this
key.
- A series of multiprecision integers comprising the key
material.
Same as v4. There is no need to change MPIs around. There are only
so many ways to store large numbers in a row.
The v5 secret keys, like the v4 secret keys, are the same as the
public key with the secret material appended.
An additional change, which is not part of the key packet format is
that v5 keys have AES as both their "last resort" and "must implement"
ciphers. When encrypting to v4 and v5 keys together, the default
cipher is 3DES. One way to look at this is that cipher preferences on
a v5 key have "AES, 3DES" implicitly at the end if not explicitly used
earlier. When combined with the implicit "3DES" already at the end of
a v4 preference list, the right thing will happen automatically. Note
that while AES is the "must" cipher for v5, implementations that
support v4 keys must also implement 3DES.
To make the transition from v4 to v5 as invisible as possible, I'd
suggest having read support for this in implementations for as long as
possible (say, 1 year) before allowing users to create these keys.
This gives time for upgrading (and there will be a certain amount of
upgrading for other reasons during that time as well, which the v5
keys can be included with), and for various other processes that
interact with OpenPGP like keyservers to be updated.
I also suggest that this not be a part of 2440bis. The v5 discussions
will undoubtedly take a while, and delaying 2440bis for an unknown
(but probably long) period of time seems a shame.
Anyway, this is a starting point. Please thow darts and make
suggestions.
David
----- End forwarded message -----