On Tue, Mar 14, 2006 at 11:44:47AM -0800, "Hal Finney" wrote:
The main question is whether we want to change the current draft to make
these changes. That would probably require backing it out of "last
call" status. Personally I think this makes sense. There is no one
waiting urgently for this draft to be finalized AFAIK. The alternative
will be to immediately amend the RFC with another RFC. But for the sake
of future implementors I think it would be better to wait a few months
more and put it all into one draft.
I agree with this. It is unfortunate, but will ultimately result in a
better RFC.
We do not have an algorithm ID for SHA-224. SHA-224 is the same
algorithm as SHA-256 but uses different initial values internally,
and then truncates the result to 224 bits. I don't see any advantage
in this case to using SHA-224 over using SHA-256 truncated to 224 bits.
However we might want to add an ID for it in case an implementor wanted
to follow the new DSS spec very closely.
Given that the main alternative is truncated SHA-256, which implies
SHA-256 support in the first place, and the code difference between
SHA-256 and 224 is simple to say the least (as you say, same
algorithm), I think we should add the ID (#7 ?) for SHA-224. It's a
checkbox item that we can trivially support.
The simplest change we could make would be to allow that DSA keys can
use modulus "p" and subgroup "q" values of the specified sizes, based
on the table above. Hashes should be equal in size or larger than the
"q" size. Hashes larger than the "q" size should be left-truncated.
Then we could note that for DSS compliance the hashes must be taken from
the SHA family, either SHA-1 or one of the larger SHA's.
We might want to think about making SHA-256 be another MUST algorithm.
The only MUST hash now is SHA-1. Making SHA-256 be a MUST would make
these new key sizes be more useful, and also give us an easier fallback
if SHA-1 should be broken.
Unless DSA2 is also a MUST, I wonder what the practical advantage to
that would be (beyond making the social point that we really, really
want people to move away from SHA-1). Since an OpenPGP program would
not necessarily know whether the recipient could handle SHA-256
(SHA-256 dates from around 2004, implementation-wise), it would have
to use SHA-1 in many or most cases anyway. Obviously a DSA2 signature
wouldn't be expected to work, but an RSA signature would have this
problem, and DSA1 (using a truncated SHA-256) would have the problem
as well for both truncation and SHA-256 reasons.
A few months back you asked the question whether new DSAs would best
be supported by extending the definition of the current DSA, or by
assigning a new algorithm ID for DSA2. At the time, most people
(myself included) felt that extending the current DSA would be the
right answer. Now that we have actual information about DSA2, perhaps
it would be worth revisiting that question. A new algorithm ID for
DSA2 resolves a number of problems in one fell swoop as there is no
expectation of interoperability. SHA-256 is always usable
(effectively the default) for DSA2, and there is no problem with
knowing when it is possible to use truncation (always).
I also think we should change the names of SHA256 etc to use dashes
as in SHA-256; those are the official names.
To be clear here: are you referring to changing the descriptive text
in the draft or changing the hash name strings as used in clearsigned
message "Hash:" headers? The first is easy and I agree should be
done, the second has compatibility implications.
David