[ietf-dkim] 1193 considered harmful

[Michael Thomas]

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.
>
> 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.ibm.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