At 6:54 PM -0500 3/24/06, Barry Leiba wrote:
Section x.y: Backward compatibility with the pre-standard version
Earlier, pre-standard implementations of DKIM used a different hash
mechanism. Owing to significant deployment of that mechanism for
early adoption and experimentation/refinement leading to this
specification, current implementations SHOULD maintain
signature-verification compatibility with the earlier version as
follows:
1. Support the SHA-1 hash algorithm, and recognize and respect the
a=rsa-sha1 tag.
Yes.
2. Support the earlier mechanism of using a single hash, as
indicated by the absence of bh=, by computing the message hash thus:
<describe how to put the headers and body together for the hash
here, noting that the canonicalization is identical>
Proposal: instead of basing this on the absence of the "bh=" header,
we really should just start using v=. They would have the identical
semantics in this case, and would be more flexible for the future.
That is, "Support the earlier mechanism of using a single hash, as
indicated by the absence of v=". We would start using "v=" in the -01
draft, maybe with a value of "-01" (although the value is truly
unimportant as long as it changes with each technical or semantic
change we make).
If people like this idea, I will propose concrete changes to the -00
text to make v= required for implementations starting with -01,
optional to include, and its absence means the protocol and semantics
pre-IETF version of the document.
Verifiers MUST NOT accept a=rsa-sha1 in the presence of bh=, and
MUST NOT accept the absence of bh= in the presence of a=rsa-SHA256;
those combinations are contrary to this specification, and their use
is NON-COMPLIANT.
Fully disagree. A few folks on this list have already said that they
can do both, and the pre-IETF versions certainly did not prohibit the
use of SHA-256.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
