Ooops, sorry about that last send.
Barry Leiba wrote:
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.
How does this address my concern? This looks like my current receiver
would fail with the new signature format. That's not backward compatable.
Mike
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html