On Fri, Sep 16, 2005 at 03:41:13PM -0700, "Hal Finney" wrote:
One issue is how best to incorporate these new key sizes. As I see it,
there are three alternatives.
1. Just use the new sizes with the existing DSA keys. Instead of only
512-1024 bits, let DSA keys also be 2048 and 3072 bits, and enforce the
proper hash algorithms in software.
2. Use a new algorithm ID for the new DSA keys, which would be only
for 2048 and 3072 bits. The old algorithm ID would continue to be
used for old DSA keys.
3. Use a new key packet version number for the new DSA keys, V5.
Perhaps V5 keys could use a SHA-256 based fingerprint. This would
represent a clean break from the old way.
The first alternative would involve the least change to the spec, just
changes to the information about how to sign and verify with DSA keys.
The second alternative would require adding much the same material
but with the handling of the new algorithm ID called out separately.
It would probably duplicate some of the information on old-style DSA keys.
The third alternative is the most ambitious and is not feasible for
RFC2440bis IMO. We could still go to a V5 key packet at some point in
the future anyway, and perhaps do other improvements at that time.
I am a big fan of V5 keys (see
http://www.imc.org/ietf-openpgp/mail-archive/msg09274.html), and I
love the clean break, but I feel that if the new DSA was tied to V5
then discussions and design for a good V5 key format would delay
availability of the new DSA in the field for an excessively long
amount of time. People have been asking for a better DSA for a long
time now, so it seems a shame to delay it further. I'm all for
planning V5 of course, just not tied to the new DSA.
Between the first two, I would propose to decide largely on the basis of
backwards compatibility. Obviously signatures made with new-style DSA
keys will not be verifiable in old code. The question is how gracefully
existing implementations will fail when presented with such keys and
signatures, in either the first or second form. Testing on current
implementations could provide guidance as to which way of making the
change will cause the least trouble.
Presuming that the size of q will change from 160 to 224 or 256 in the
new key, importing a DSA key to GnuPG with the current algorithm
number and a q that is not 160 bits or importing a new-style DSA key
with a new algorithm number fails more or less gracefully in either
case.
So at least from the graceful failure perspective in GnuPG, it doesn't
really matter much which way we go. I prefer the first option (using
the current algorithm number) since it seems cleanest in both code and
standard.
David