RFC 4871, "DomainKeys Identified Mail (DKIM) Signatures", May 2007

Note: This RFC has been obsoleted by RFC 6376

Note: This RFC has been updated by RFC 5672

Errata ID: 1596
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Hansen
Date Reported: 2008-11-17
Held for Document Update by: Sean Turner

Section 2.4/3.7 says:

Here're the relevant portions of RFC 4871 

   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

It 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 the base64string grammar to remove leading and trailing FWS:

     ALPHADIGITPS =     (ALPHA / DIGIT / "+" / "/")

     base64string =     ALPHADIGITPS *([FWS] ALPHADIGITPS)
                        [ [FWS] "=" [ [FWS] "=" ] ]

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

Report New Errata