I just filed Errata 1596 on the base spec. The errata is here
http://www.rfc-editor.org/errata_search.php?eid=1596 The description is
below.
Tony Hansen
tony(_at_)att(_dot_)com
Here're the relevant portions of RFC 4871, sections 2.4 and 3.7:
2.4. Common ABNF Tokens
The following ABNF tokens are used elsewhere in this document:
base64string = 1*(ALPHA / DIGIT / "+" / "/" / [FWS])
[ "=" [FWS] [ "=" [FWS] ] ]
3.7. Computing the Message Hashes
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.
Sections 3.2 and 3.5 have this to say:
3.2. Tag=Value Lists
Formally, the syntax rules are as follows:
tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ]
tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-name = ALPHA 0*ALNUMPUNC
tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ]
; WSP and FWS prohibited at beginning and end
tval = 1*VALCHAR
Note that WSP is allowed anywhere around tags. In particular, any
WSP after the "=" and any WSP before the terminating ";" is not part
of the value; however, WSP inside the value is significant.
3.5. The DKIM-Signature Header Field
The signature of the email is stored in the DKIM-Signature header
field. This header field contains all of the signature and key-
fetching data. The DKIM-Signature value is a tag-list as described
in Section 3.2.
...
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
Notes:
The issues are, what constitutes the *value* of the b= tag? Is it
everything after the "=" through any following ";" and/or the end of the
header? Does that include or exclude surrounding white space? Is it
specifically the characters that constitute "tag-val" /
"sig-b-tag-data"? Does sig-b-tag-data include or exclude white space?
Notice how the section 3.5 "b=" deletion description talks about adding
FWS "in" the value, but not "before" or "after".
Notice that the section 3.2 definition of tag-val
tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ]
; WSP and FWS prohibited at beginning and end
explicitly does *not* include either the FWS before its value or after.
And the text in section 3.2 explicitly says that the surrounding WSP is
not part of the value.
And notice that the section 3.5 grammar around sig-b-tag-data
sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data
sig-b-tag-data = base64string
explicitly mentions FWS as being separate from the data.
By the above definitions, tag-val and sig-b-tag-data explicitly do *not*
include the FWS either before or after it.
However, the definition of base64string
base64string = 1*(ALPHA / DIGIT / "+" / "/" / [FWS])
[ "=" [FWS] [ "=" [FWS] ] ]
tosses FWS in to its production. So it is ambiguous from the grammar
whether the leading/trailing FWS is part of sig-b-tag-data or part of
base64string. (This grammar ambiguity is in *all* of the uses of
base64string in sections 3.5 and 3.6.1.)
In addition, the text in the section 3.5 b= description certainly
implies that white space before and after the hash should not affect the
verification.
So by these, "with the value of the 'b=' tag deleted" could mean 1)
everything after the "=" which includes the leading/trailing white
space, 2) the *tag-value* grammar production which excludes
leading/trailing white space, or 3) the *sig-b-tag-data* grammar
production that may or may not include leading/trailing white space.
**This is an ambiguity (a bug) in the spec.**
Section 3.7 should say:
Add text "(including all surrounding whitespace)" to the description of
deleting the b= value.
3.7. Computing the Message Hashes
2. The DKIM-Signature header field that exists (verifying) or will
be inserted (signing) in the message, with the value of the "b="
tag (including all surrounding whitespace) deleted
(i.e., treated as the empty string), canonicalized
using the header canonicalization algorithm specified in the "c="
tag, and without a trailing CRLF.
Fix the ambiguity in using the base64string grammar to remove leading
and trailing FWS:
ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/")
base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS)
[ [FWS] "=" [ [FWS] "=" ] ]
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html