Murray S. Kucherawy wrote:
> 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".
Yeah, I saw those as I was looking at the diffs between 00 and 01. Those
corrections corroborate how I interpreted it.
> 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.
Should the CRLF be there or not between the canonicalized headers and
the DKIM-Signature? I expect it to be there, but this paragraph is the
only place that says it should be there.
The signature in -00 was generated from "header CRLF body CRLF
dkim-signature". Now I expect it to be generated from "header CRLF
dkim-signature". That is, the "body CRLF" disappears, but not *both* CRLFs.
Am I wrong?
Tony Hansen
[EMAIL PROTECTED]
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
