Subject: [ietf-dkim] Clarifications on draft-ietf-dkim-base-01

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 18 Apr 2006 13:27:25 -0700

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.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Tony Hansen <[email-masked]>
Date: Tue, 18 Apr 2006 16:49:34 -0400

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

> 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-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 18 Apr 2006 14:10:00 -0700

> only place that says it should be there.

No, it should not.  This says exactly how to do it:

    In hash step 2, the signer or verifier MUST pass the following to the
    hash algorithm in the indicated order.

    1.  The header fields specified by the "h=" tag, in the order
        specified in that tag, and canonicalized using the header
        canonicalization algorithm specified in the "c=" tag.  Each
        header field must be terminated with a single CRLF.

    2.  The "DKIM-Signature" header field that exists (verifying) or will
        be inserted (signing) in the message, with the value of the "b="
        tag deleted (i.e., treated as the empty string), canonicalized
        using the header canonicalization algorithm specified in the "c="
        tag, and without a trailing CRLF.

There's no intervening CRLF.

> dkim-signature". That is, the "body CRLF" disappears, but not *both* CRLFs.

My understanding after talking to Eric:

The body hash is of the body only; no extra CRLFs and no signature.

The header hash contains the headers to be signed (if signing) or the headers 
replayed according to the "h=" tag value (if verifying), followed by the 
signature being evaluated (if verifying) or generated (if signing) minus the 
"b=" value.  Again, no extra CRLFs.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Tony Hansen <[email-masked]>
Date: Tue, 18 Apr 2006 17:45:46 -0400

Which is just the opposite of what I expected. I'm willing to change my
implementation to use this interpretation instead, but I think this
clarification by itself is reason enough to get a -02 out as quickly as
possible.

	Tony Hansen
	[email-masked]

Murray S. Kucherawy wrote:
>> ...
> The header hash contains the headers to be signed (if signing) or the
> headers replayed according to the "h=" tag value (if verifying),
> followed by the signature being evaluated (if verifying) or generated
> (if signing) minus the "b=" value.  Again, no extra CRLFs.

---

From: Eric Allman <[email-masked]>
Date: Tue, 18 Apr 2006 15:14:33 -0700

--On April 18, 2006 5:45:46 PM -0400 Tony Hansen <[email-masked]> wrote:

> ...  I think this
> clarification by itself is reason enough to get a -02 out as
> quickly as possible.

Agreed.  I'm going to try to fold in the various comments I've 
received and then get -02 out.

I'm at a conference for the next few days, but I'll try to do this 
over the weekend.

eric