errata logo graphic

Found 16 records.

Status: Verified (7)

RFC4871, "DomainKeys Identified Mail (DKIM) Signatures", May 2007

Note: This RFC has been obsoleted by RFC6376

Source of RFC: dkim (sec)

Errata ID: 1376

Status: Verified
Type: Technical

Reported By: Tony Hansen
Date Reported: 2008-03-21
Verifier Name: Pasi Eronen
Date Verified: 2009-05-14

Section 3.4.3/.4 says:

section 3.4.3 & section 3.4.4

It should say:

Add to end of section 3.4.3:

   The sha1 value (in base64) for an empty body (canonicalized to a "CRLF") is "uoq1oCgLlTqpdDX/iUbLy7J1Wic=".
   The sha256 value is "frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=".

Add to end of section 3.4.4:

   The sha1 value (in base64) for an empty body (canonicalized to a null input) is "2jmj7l5rSw0yVb/vlWAYkK/YBwk=".
   The sha256 value is "47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=".

Notes:

From the October 2008 interop event:

Empty message bodies
• the “simple” body canonicalization says precisely what to do in the case of an empty message body
• “relaxed” does not
• Consensus is that the “relaxed” body canonicalization of the null body is the null input
• Majority felt it was conspicuous that “simple” was explicit while “relaxed” was not
• Errata: add clarification statement on expected values for relaxed


Errata ID: 1377

Status: Verified
Type: Technical

Reported By: Tony Hansen
Date Reported: 2008-03-21
Verifier Name: Pasi Eronen
Date Verified: 2009-05-14

Section 3.4.4 says:

---

It should say:

Add a 4th bullet item to section 3.4.4:

o  If the body is non-empty, but does not end with a CRLF, a CRLF is 
   added.  (For email, this is only possible when using extensions to
   SMTP or non-SMTP transport mechanisms.)

Notes:

From the October 2008 interop event:

No Trailing CR-LF
* What if body is non-empty, but does not end in CRLF?
* Only possible with BDAT or non-SMTP transport mechanisms
* “simple” (§3.4.3) says to add a CRLF
* “relaxed” (§3.4.4) says nothing
* Consensus is to add a CRLF for Relaxed if
– it was missing and
– the body is not empty
– Errata: Add statement on what to do for Relaxed


Errata ID: 1378

Status: Verified
Type: Technical

Reported By: Tony Hansen
Date Reported: 2008-03-21
Verifier Name: Pasi Eronen
Date Verified: 2009-05-14

Section 3.3 says:

The rsa-sha256 algorithm is the default if no algorithm is specified. 

It should say:

(nothing)

Notes:

According to 3.5, including "a=" is REQUIRED, so the algorithm is
always specified, and there is no default.


Errata ID: 1379

Status: Verified
Type: Technical

Reported By: Tony Hansen
Date Reported: 2008-03-21
Verifier Name: Pasi Eronen
Date Verified: 2009-05-14

Section 3.5 says:

       sig-z-tag      = %x7A [FWS] "=" [FWS] sig-z-tag-copy
                    *( [FWS] "|" sig-z-tag-copy )
   sig-z-tag-copy = hdr-name ":" qp-hdr-value

It should say:

       sig-z-tag      = %x7A [FWS] "=" [FWS] sig-z-tag-copy
                    *( "|" [FWS] sig-z-tag-copy )
   sig-z-tag-copy = hdr-name [FWS] ":" qp-hdr-value

Notes:

From the October 2008 interop event, there are several issues with z=:

FWS in z= tag

1) Does not allow any FWS between the "|" and the following header name in sig-z-tag-copy

2) By the ABNF, the informative example that immediately follows is invalid:

z=From:foo@eng.example.net|To:joe@example.com|
----Subject:demo=20run|Date:July=205,…

3) The [FWS] is redundant there; sig-z-tag-copy ends with qp-hdr-value, which can already end with arbitrary FWS

4) No FWS allowed between the hdr_name and the following ":“:

The modified ABNF is not redundant and agrees with the example.


Errata ID: 1384

Status: Verified
Type: Technical

Reported By: Tony Hansen
Date Reported: 2008-03-22
Verifier Name: Pasi Eronen
Date Verified: 2009-05-14

Section 4.3.4 says:

   The "relaxed" body canonicalization algorithm:

   o  Ignores all whitespace at the end of lines.  Implementations MUST
      NOT remove the CRLF at the end of the line.

   o  Reduces all sequences of WSP within a line to a single SP
      character.

   o  Ignores all empty lines at the end of the message body.  "Empty
      line" is defined in Section 3.4.3.


It should say:

   The "relaxed" body canonicalization algorithm MUST apply the
   following steps (a) and (b) in order:

   a) Reduce whitespace:
      *  Ignore all whitespace at the end of lines.  Implementations MUST
         NOT remove the CRLF at the end of the line.

      *  Reduce all sequences of WSP within a line to a single SP
         character.

   b)  Ignore all empty lines at the end of the message body.  "Empty
      line" is defined in Section 3.4.3.


Notes:

This was discussed on the dkim interop mailing list.

You can wind up with different results depending on whether steps 1 and 3 are executed in that order or swapped around. Half of the implementations were found to do it one way and another half the other way.

It was decided that the same text applied to section 4.3.2

The "relaxed" header canonicalization algorithm MUST apply the
following steps in order:

should be used in 4.3.4 as well, that is

The "relaxed" body canonicalization algorithm MUST apply the
following steps in order:

But since steps 1&2 can still be done in either order, make those sub-bullets of step 1.

Just to be totally clear, following this decision we would wind up with this sequence.

Given this input:

testing<cr><lf>
<sp><sp><cr><lf>
<cr><lf>

a) Reduce whitespace:
* Ignore all whitespace at the end of lines. Implementations MUST
NOT remove the CRLF at the end of the line.

testing<cr><lf>
<cr><lf>
<cr><lf>

* Reduce all sequences of WSP within a line to a single SP
character.

testing<cr><lf>
<cr><lf>
<cr><lf>

b) Ignore all empty lines at the end of the message body. "Empty
line" is defined in Section 3.4.3.

testing<cr><lf>

If the two steps in (a) are performed in the opposite order,

testing<cr><lf>
<sp><sp><cr><lf>
<cr><lf>

a) Reduce whitespace:
* Reduce all sequences of WSP within a line to a single SP
character.

testing<cr><lf>
<sp><cr><lf>
<cr><lf>

* Ignore all whitespace at the end of lines. Implementations MUST
NOT remove the CRLF at the end of the line.

testing<cr><lf>
<cr><lf>
<cr><lf>

b) Ignore all empty lines at the end of the message body. "Empty
line" is defined in Section 3.4.3.

testing<cr><lf>


Errata ID: 1461

Status: Verified
Type: Technical

Reported By: Frank Ellermann
Date Reported: 2008-07-04
Verifier Name: Pasi Eronen
Date Verified: 2009-05-14

Section 3.5 says:

       sig-h-tag       = %x68 [FWS] "=" [FWS] hdr-name
                     0*( *FWS ":" *FWS hdr-name )

It should say:

       sig-h-tag       = %x68 [FWS] "=" [FWS] hdr-name
                     0*( [FWS] ":" [FWS] hdr-name )

Notes:

Confirmed by many occurrences of [FWS] in this section the intention is to allow optional "folding white space" with at most one folding. Compare section 2.3 in this memo for the rationale; more than one folding is known as <obs-FWS> in RFC 2822 and MUST NOT be generated.


Errata ID: 1487

Status: Verified
Type: Technical

Reported By: Murray S. Kucherawy
Date Reported: 2008-08-14
Verifier Name: Pasi Eronen
Date Verified: 2009-05-14

Section 3.6.1 says:

   v=  Version of the DKIM key record (plain-text; RECOMMENDED, default
       is "DKIM1").  If specified, this tag MUST be set to "DKIM1"
       (without the quotes).  This tag MUST be the first tag in the
       record.  Records beginning with a "v=" tag with any other value
       MUST be discarded.  Note that verifiers must do a string
       comparison on this value; for example, "DKIM1" is not the same as
       "DKIM1.0".

       ABNF:

       key-v-tag    = %x76 [FWS] "=" [FWS] "DKIM1"

It should say:

   v=  Version of the DKIM key record (plain-text; RECOMMENDED, default
       is "DKIM1").  If specified, this tag MUST be set to "DKIM1"
       (without the quotes).  This tag MUST be the first tag in the
       record.  Records beginning with a "v=" tag with any other value
       MUST be discarded.  Note that verifiers must do a string
       comparison on this value; for example, "DKIM1" is not the same as
       "DKIM1.0".

       ABNF:

       key-v-tag    = %x76 [FWS] "=" [FWS] %x44 %x4B %x49 %x4D %x31

Notes:

RFC5234 section 2.3 says string literals in ABNF are case-insensitive. However, RFC4871 section 3.2 says tag values are case-sensitive unless stated otherwise. This renders the defintion of "v=" in section 3.6.1 of this RFC ambiguous.

Therefore, one interpretation of "DKIM1" here allows "dkim1" and one does not.

Either the "case-sensitive" nature of tag values should be changed, or the ABNF needs to be revised to be more precise.


Status: Held for Document Update (7)

RFC4871, "DomainKeys Identified Mail (DKIM) Signatures", May 2007

Note: This RFC has been obsoleted by RFC6376

Source of RFC: dkim (sec)

Errata ID: 1380

Status: Held for Document Update
Type: Technical

Reported By: Tony Hansen
Date Reported: 2008-03-21
Held for Document Update by: Pasi Eronen

Section 3.5 says:

       INFORMATIVE NOTE: The "x=" tag is not intended as an anti-replay
           defense.

It should say:

       INFORMATIVE NOTE: The "x=" tag is not intended as an anti-replay
           defense.
       INFORMATIVE NOTE: Due to clock drift, the receiver’s notion of 
when to consider the signature expired may not match exactly when the 
sender is expecting. Receiver’s MAY add a 'fudge factor' to allow for 
such possible drift.

Notes:

From the October 2008 interop event:

When does x= take effect?
* §3.5 says the “x=” value is an “absolute date”
* A receiver’s notion of absolute time might not match the sender’s notion of absolute time
* The document may not expire exactly when sender thinks it should
* A receiving implementation has these choices:
- Try to decide how far apart sender’s notion of absolute time is from the receiver’s notion of absolute time, based on header information
- Use local knowledge of what the absolute time is
- Add in a “fudge factor” to acknowledge possible clock drift


Errata ID: 1381

Status: Held for Document Update
Type: Technical

Reported By: Tony Hansen
Date Reported: 2008-03-21
Held for Document Update by: Pasi Eronen

Section 3.5/3.6.1 says:

section 3.5:

   q=  A colon-separated list of query methods used to retrieve the
       public key ... Implementations MUST use the recognized query
       mechanisms in the order presented.

section 3.6.1:

   h=  Acceptable hash algorithms ... Signers and Verifiers MUST
       support the "sha256" hash algorithm.  Verifiers MUST also support
       the "sha1" hash algorithm.

   k=  Key type ... (Note: the "p=" tag further encodes the value using the
       base64 algorithm.)

   s=  Service Type ... Verifiers for a given service type MUST ignore this 
       record if the appropriate type is not listed.  Currently defined 
       service types are as follows:

   t=  Flags, represented as a colon-separated list of names (plain-
       text; OPTIONAL, default is no flags set).  The defined flags are
       as follows:

It should say:

section 3.5:

   q=  A colon-separated list of query methods used to retrieve the
       public key ...  Implementations MUST use the recognized query
       mechanisms in the order presented. Unrecognized query mechanisms
       MUST be ignored.

section 3.6.1:

   h=  Acceptable hash algorithms ... Signers and Verifiers MUST
       support the "sha256" hash algorithm.  Verifiers MUST also support
       the "sha1" hash algorithm. Unrecognized hash algorithms MUST be 
       ignored.

   k=  Key type ...(Note: the "p=" tag further encodes the value using the
       base64 algorithm.) Unrecognized key types MUST be ignored.

   s=  Service Type ... Verifiers for a given service type MUST ignore this 
       record if the appropriate type is not listed. Unrecognized service 
       types MUST be ignored. Currently defined service types are as follows:

   t=  Flags, represented as a colon-separated list of names (plain-
       text; OPTIONAL, default is no flags set).  Unrecognized flags MUST be 
       ignored. The defined flags are as follows:

Notes:

From the October 2008 interop event:

Invalid q=, etc. values

* q=foo/bar:dns/txt:exam/ple
* Nothing in text about unknown values
* But ABNF says unknown values are for “future extension”
* Consensus: ignore unknown values
* Errata: Add statement saying unknown values must be ignored in signature “q=” and key “h=”, “k=”, “s=”, “t=”


Errata ID: 1382

Status: Held for Document Update
Type: Technical

Reported By: Tony Hansen
Date Reported: 2008-03-21
Held for Document Update by: Pasi Eronen

Section 3.6.1 says:

   s=  Service Type (plain-text; OPTIONAL; default is "*").  A colon-
       separated list of service types to which this record applies.
       Verifiers for a given service type MUST ignore this record if the
       appropriate type is not listed.  Currently defined service types
       are as follows:

       *   matches all service types

       email   electronic mail (not necessarily limited to SMTP)

       This tag is intended to constrain the use of keys for other
       purposes, should use of DKIM be defined by other services in the
       future.

It should say:

   s=  Service Type (plain-text; OPTIONAL; default is "*").  A colon-
       separated list of service types to which this record applies.
       Verifiers for a given service type MUST ignore this record if the
       appropriate type is not listed.  Currently defined service types
       are as follows:

       *   matches all service types

       email   electronic mail (not necessarily limited to SMTP)

       Unrecognized service types MUST be ignored.

       This tag is intended to constrain the use of keys for other
       purposes, should use of DKIM be defined by other services in the
       future.

Notes:

From the October 2008 interop event:

DNS Key Interoperability Issues: “s=” in key records

* §3.6.1 doesn't say what to do if one of the colon-separated words is a word not enumerated in the “currently defined service types”
s=foo:email:bar
* No explicit guidance about what to do with clearly bogus values, e.g.
s=*:email
* Consensus is to ignore any colon-separated value not recognized and only pay attention to “*” and “email” for DKIM e-mail implementations


Errata ID: 1386

Status: Held for Document Update
Type: Technical

Reported By: Mark Delany
Date Reported: 2008-03-24
Held for Document Update by: Pasi Eronen

Section 3.5 says:

DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane;

It should say:

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;

Notes:

The example is missing the v= tag which MUST be included.


Errata ID: 1532

Status: Held for Document Update
Type: Technical

Reported By: Tony Hansen
Date Reported: 2008-09-30
Held for Document Update by: Sean Turner

Section 3.6.1 says:

N/A (see Notes below)

It should say:

Add text similar to the following:

Compatibility Note for DomainKeys

If a v= value is not found at the beginning of the DKIM key record, 
the key record should be interpreted as for DomainKeys [4870]. The 
definition given here is upwardly compatible with what is used for 
DomainKeys, with the exception of the "g=" value. In a DomainKeys 
key record, an empty "g=" value should be interpreted as being 
equivalent to DKIM's "g=*".

Notes:

There should be a note added somewhere to section 3.6.1 saying
that if a v= is not found at the beginning of the DKIM key
record, the DNS key record should be interpreted as for DomainKeys
and described in RFC 4870. In addition, a note should be added
about the difference in the interpretation of an empty "g=",
which is the only incompatible tag.


Errata ID: 1596

Status: Held for Document Update
Type: Technical

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


Errata ID: 1383

Status: Held for Document Update
Type: Editorial

Reported By: Tony Hansen
Date Reported: 2008-03-21
Held for Document Update by: Pasi Eronen
Date Held: 2009-05-05

Section 3.6.1 says:

   g=  Granularity of the key (plain-text; OPTIONAL, default is "*").
       ....  Wildcarding allows matching for addresses such as
       "user+*" or "*-offer".  An empty "g=" value never matches any
       addresses.

It should say:

   g=  Granularity of the key (plain-text; OPTIONAL, default is "*").
       ....  Wildcarding allows matching for addresses such as
       "user+*", "*-offer", or "foo*bar". An empty "g=" value never 
       matches any addresses.

Notes:

The ABNF allows "*" in the middle (but only one), and this should
be shown in the examples, too.


Status: Rejected (2)

RFC4871, "DomainKeys Identified Mail (DKIM) Signatures", May 2007

Note: This RFC has been obsoleted by RFC6376

Source of RFC: dkim (sec)

Errata ID: 1385

Status: Rejected
Type: Technical

Reported By: Murray S. Kucherawy
Date Reported: 2008-03-23
Rejected by: Pasi Eronen
Date Rejected: 2010-02-11

Section 3.6.1 says:

It is expected that many key servers will choose to present the keys in an
otherwise unstructured text format (for example, an XML form would not be
considered to be unstructured text for this purpose).  The following definition
MUST be used for any DKIM key represented in an otherwise unstructured textual
form.

It should say:

It is expected that many key servers will choose to present the keys in an
otherwise unstructured text format (for example, an XML form would not be
considered to be unstructured text for this purpose).  The following definition
MUST be used for any DKIM key represented in an otherwise unstructured textual
form.

The TXT RDATA format is described in section 3.3.14 of RFC1035.  If the retrieved
TXT record consists of more than one "character-string" (as defined in that
document), the RDATA MUST be preprocessed by concatenating all of the
"character-string"s together in the order in which they appeared in the RDATA
before being interpreted as described below.

Notes:

No guidance is provided about how to handle a single TXT RDATA which is subdivided into multiple character-strings, such as an encoded public key that is too large to fit in such a construct (which is limited by RFC1035 to be each 255 characters or less).
--VERIFIER NOTES--
Section 3.6.2.2 already specifies the necessary details.


Errata ID: 1942

Status: Rejected
Type: Technical

Reported By: Murray S. Kucherawy
Date Reported: 2009-11-11
Rejected by: Pasi Eronen
Date Rejected: 2010-03-01

Section 3.4.4 says:

The "relaxed" body canonicalization algorithm:

It should say:

The "relaxed" body canonicalization algorithm MUST apply the following 
steps in order:

Notes:

The order of the steps should be enforced, as in section 3.4.2. I have two disagreeing interpretations that have resulted in an interoperability problem (fortunately a corner case), namely:

<CRLF><CRLF><SP><SP><CRLF> should be canonicalized as what? Taken top-to-bottom, the output is the empty body; given the other pending errata, the output should be a single <CRLF>; yet another interpretation strips trailing <CRLF>s first, then does space trimming, leaving the output as <CRLF><CRLF><CRLF>.

I might further suggest changing these steps to an enumerated/ordered list instead of a list of bullet points.
--VERIFIER NOTES--
Duplicate; this issue is already covered by errata 1384.


Report New Errata