On Thu, Mar 16, 2006 at 12:19:51PM -0800, "Hal Finney" wrote:
David Shaw writes:
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.
OK, but maybe a "SHOULD" like Werner suggested, then?
Absolutely. I'm in favor of SHOULD. This implies that DSA with
160-bit q is a MUST (as it is now), and DSA with >160-bit q is not a
MUST (though an implementation must at least know that DSA might have
a larger q and not blow up).
At this point I like the idea of keeping the same algorithm ID. All the
code and algorithms are the same, so using a different alg ID just
for different key sizes doesn't really make sense. Using a different
algorithm ID will be, from the future perspective, a historical artifact.
And I don't see that it really helps interoperability to use a new ID.
Either way, the bottom line is that old code won't work with the new
keys and new code will. Plus it makes implementation of the change a
lot easier - granted, a minor point, but on top of everything else I
see this as the preferable strategy.
While I agree that the bottom line is that the old code won't work and
the new code will, using a different algorithm ID potentially gives a
better (and more user-comprehensible) error than using the same
algorithm ID does when the old code doesn't work. That is to say, it
may fail "prettier" (it does in the GPG case). I don't think it's
that big of a deal, and I'm not arguing for it.
On a related issue, do you think a feature flag to indicate the
ability to handle a truncated hash would be a good idea? I'm leaning
towards no, as it would only be really useful in the sign+encrypt case
(where the implementation knows who the recipient(s) are and can thus
consult feature flags), but perhaps that's enough to justify it.
David