I have a suggestion that I think might (ha!) satisfy everyone. That is,
I THINK it will satisfy those who want the separate body hash, it will
address Mike's compatibility concern, and it will not give Mark hives
because of overloaded tags and burgeoning combinatorics.
Suppose the base doc said this sort of thing:
---------------------------------------------------------
... signers MUST use a=rsa-sha256 ...
... hash the body and put the hash value in bh= ...
... hash the headers, sign that hash, put the signature into b= ...
... etc, etc, etc ...
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.
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>
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.
---------------------------------------------------------
What do y'all think (I picked that up in Dallas)?
Barry
--
Barry Leiba, Pervasive Computing Technology
(leiba(_at_)watson(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html