Subject: [ietf-dkim] errata 1596 on dkim base spec

From: Tony Hansen <[email-masked]>
Date: Mon, 17 Nov 2008 11:20:52 -0500

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

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