On Fri, Sep 16, 2005 at 03:41:13PM -0700, "Hal Finney" wrote:
The new DSS keys will, according to what I have heard, be for two sizes:
2048 and 3072 bits, and will use SHA-224 and SHA-256 respectively.
(SHA-224 is not presently an OpenPGP algorithm; it is basically a
truncated version of SHA-256 with a different internal initial value).
This will allow for larger keys and use a different hash than SHA-1.
For this reason, I'd agree with Ian and just ignore the 2048/224 key
specification. Too much trouble for no gain.
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.
I like this solution. If old implementations do not do very silly things
when encountering such signatures (e.g. claiming them to be bad signatures
as opposed to unverifiable), it is the cleanest way to go about it.
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.
This approach would eat up the algorithm identifier space and provide very
little advantage. It is reasonable to expect new DSS key specifications
every decade, if NIST continues its current practices.
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.
Let's wait with that. There are several problems with the v4 key formats and
using SHA-256 for fingerprinting is not necessarily a good idea, given that
its design is quickly becoming obsolete.
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.
That's a very reasonable suggestion.
--
Daniel