Subject: [ietf-dkim] need an interpretation of the base spec

From: Tony Hansen <[email-masked]>
Date: Tue, 03 Jun 2008 16:44:01 -0400

I need an interpretation of the base spec here.

RFC 4871 section 3.5:
    b=  The signature data (base64; REQUIRED).  Whitespace is ignored in
        this value and MUST be ignored when reassembling the original
        signature.  In particular, the signing process can safely insert
        FWS in this value in arbitrary places to conform to line-length
        limits.  See Signer Actions (Section 5) for how the signature is
        computed.

    ABNF:

        sig-b-tag       = %x62 [FWS] "=" [FWS] sig-b-tag-data
        sig-b-tag-data  = base64string

RFC 4871 section 3.7:

    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.

The test case has a DKIM signature that looks like this:

DKIM-Signature: v=1; q=dns/txt; d=example.com; s=sel1; a=rsa-sha256;^M
      h=Content-Transfer-Encoding:Content-Type:Subject:MIME-Version:^M
      From:Date:To; bh=HryPFX2R6r7JPsX1Z7+yReZddQR2PjvCvdXgaxW5QYU=; b=^M
      dMozOMJVKhnCk7NnC7lqWIdhwU7Jv3DzAmoEC+Ums0KqAe9FOhqPCtbCAN^M
      061sS2aiKRDA8pzjTeFBsF40yDuYyvJ85ZY1PR5O736DeBEHGw3QX3s9/^M
      LRFcqXV2na7YkJorUyMm4BXDSgmpW3TR8GiiUNXXKaHeucvxxOr3Lq0g=^M

Note how the "b=" is separated from the hash key by the CRLF and white 
space.

Now the question: Does the "value of the 'b=' tag" (that is deleted per 
section 3.7) mean 1) exactly the sig-b-tag-data, or 2) does it include 
the [FWS] between the "=" and the sig-b-tag-data?

Depending on the order you do the remove and canonicalization, and your 
answer to the above question, if #1, then the canonicalized form of the 
DKIM-Signature will use
	c=simple	"b=     "
	c=relaxed	"b= "

And if #2, then the canonicalized form of the DKIM-Signature will use
	c=either	"b="

I've seen two different interpretations of this. Of 3 different 
reflectors I got responses from, 2 appear to follow #2 and 1 appears to 
follow #1. One version of my own code is whitespace-preserving, as in 
#1, but another set of code I wrote is not, as in #2. Argh!

Right now, I'm leaning towards thinking that #2 is correct. What say the 
rest of you?

	Tony Hansen
	[email-masked]
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Jun 2008 14:52:00 -0700 (PDT)

> Right now, I'm leaning towards thinking that #2 is correct. What say the

Discarding FWS and tokenizing is probably a common implementation tactic, 
which favours #2.

I'm inclined to say it's an errata issue (and would offer #2 as the 
preferred implementation) unless someone can show precedent for resolution 
of something similar in the past.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html