[ietf-dkim] 1193 considered harmful

Paul Hoffman phoffman at proper.com
Sat Mar 25 08:41:41 PST 2006


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.


More information about the ietf-dkim mailing list