There are a few spots in the newer draft which are ambiguous. I chatted with
Eric yesterday and he concurs; it's stuff he meant to change but they fell
through the cracks prior to submission. They'll be fixed in the next one.
My implementation follows the intended algorithm as we discussed it, so here are
the few points of clarification, all from section 3.7:
In hash step 1, the signer or verifier MUST hash the message body,
canonicalized using the header canonicalization algorithm specified
in the "c=" tag and truncated to the length specified in the "l="
tag. That hash value is then converted to base64 form and inserted
into the "XXX=" tag of the DKIM-Signature: header field.
Obviously that should say the body is canonicalized using the body
canonicalization algorithm specified (or implied) in the "c=" tag, not the
header algorithm. Also obviously, "XXX" should be "bh".
After the body is processed, a single CRLF followed by the "DKIM-
Signature" header field being created or verified is presented to the
algorithm. The value portion of the "b=" tag (that is, the portion
after the "=" sign) must be treated as though it were empty, and the
header field must be canonicalized according to the algorithm that is
specified in the "c=" tag. Any final CRLF on the "DKIM-Signature"
header field MUST NOT be included in the signature computation.
This paragraph should be ignored completely. It should have been removed.
_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev