RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 10 records.

Status: Verified (8)

RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures", September 2011

Source of RFC: dkim (sec)

Errata ID: 3192
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: John Hawthorn
Date Reported: 2012-04-14
Verifier Name: Barry Leiba
Date Verified: 2012-04-14

Section Appendix A says:

   From: Joe SixPack <joe@football.example.com>
   To: Suzie Q <suzie@shopping.example.net>
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: <20030712040037.46341.5F8J@football.example.com>

   Hi.

   We lost the game.  Are you hungry yet?

   Joe.

It should say:

   From: Joe SixPack <joe@football.example.com>
   To: Suzie Q <suzie@shopping.example.net>
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: <20030712040037.46341.5F8J@football.example.com>

   Hi.

   We lost the game. Are you hungry yet?

   Joe.

Notes:

This text appears three times, in A.1, A.2, and A.3. Notice the double space after "game.", which renders the body hashes in A.2 and A.3 invalid.

The corrected text, which is the same as that in RFC 4871, removes the extra space.

Errata ID: 4810
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Juan Altmayer Pizzorno
Date Reported: 2016-09-26
Verifier Name: Stephen Farrell
Date Verified: 2016-09-27

Section 3.5 says:

x-sig-q-tag-args = qp-hdr-value

It should say:

x-sig-q-tag-args = dkim-quoted-printable  ; with ":" encoded

Notes:

sig-q-tag-methods are ":"-separated in sig-q-tag, so ":" shouldn't be permitted
within x-sig-q-tag-args. Note that qp-hdr-value (which I believe was originally
defined for sig-z-tag, which includes "|"-separated values) is defined as

qp-hdr-value = dkim-quoted-printable ; with "|" encoded

Errata ID: 5070
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Chris Newman
Date Reported: 2017-07-15
Verifier Name: Barry Leiba
Date Verified: 2019-04-30

Section 3.2 says:

   tag-spec  =  [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
   tag-name  =  ALPHA *ALNUMPUNC
   tag-value =  [ tval *( 1*(WSP / FWS) tval ) ]
                     ; Prohibits WSP and FWS at beginning and end

It should say:

   tag-spec  =  [FWS] tag-name [FWS] "=" [FWS] [tag-value [FWS]]
   tag-name  =  ALPHA *ALNUMPUNC
   tag-value =  tval *( 1*(WSP / FWS) tval )
                     ; Prohibits WSP and FWS at beginning and end

Notes:

The ABNF in the document permits two FWS rules to appear in the row. This results in permitting a line with only whitespace in the header which falls into obsolete syntax in RFC 5322 (Appendix B rule 12). The corrected text disallows this by eliding the second FWS when the tag-value is empty/omitted.

Errata ID: 5137
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Peter Smith
Date Reported: 2017-10-03
Verifier Name: Alexey Melnikov
Date Verified: 2017-10-18

Section 3.6.1 says:

      key-k-tag        = %x76 [FWS] "=" [FWS] key-k-tag-type

It should say:

      key-k-tag        = %x6b [FWS] "=" [FWS] key-k-tag-type

Notes:

The key-k-tag should (presumably) start with the letter "k" to match the other key-LETTER-tag definitions and to match the "k=" heading. However, the ABNF specifies %76 which is the letter "v", not the letter "k". The correct value is %x6b.

Errata ID: 5252
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Alastair Houghton
Date Reported: 2018-02-02
Verifier Name: Barry Leiba
Date Verified: 2019-04-30

Section 3.7 says:

   More formally, pseudo-code for the signature algorithm is:

   body-hash    =  hash-alg (canon-body, l-param)
   data-hash    =  hash-alg (h-headers, D-SIG, body-hash)
   signature    =  sig-alg (d-domain, selector, data-hash)

   where:

   body-hash:  is the output from hashing the body, using hash-alg.

   hash-alg:   is the hashing algorithm specified in the "a" parameter.

   canon-body: is a canonicalized representation of the body, produced
               using the body algorithm specified in the "c" parameter,
               as defined in Section 3.4 and excluding the
               DKIM-Signature field.

   l-param:    is the length-of-body value of the "l" parameter.

   data-hash:  is the output from using the hash-alg algorithm, to hash
               the header including the DKIM-Signature header, and the
               body hash.

   h-headers:  is the list of headers to be signed, as specified in the
               "h" parameter.

   D-SIG:      is the canonicalized DKIM-Signature field itself without
               the signature value portion of the parameter, that is, an
               empty parameter value.

It should say:

   More formally, pseudo-code for the signature algorithm is:

   body-hash    =  hash-alg (canon-body, l-param)
   data-hash    =  hash-alg (h-headers, D-SIG)
   signature    =  sig-alg (d-domain, selector, data-hash)

   where:

   body-hash:  is the output from hashing the body, using hash-alg.

   hash-alg:   is the hashing algorithm specified in the "a" parameter.

   canon-body: is a canonicalized representation of the body, produced
               using the body algorithm specified in the "c" parameter,
               as defined in Section 3.4 and excluding the
               DKIM-Signature field.

   l-param:    is the length-of-body value of the "l" parameter.

   data-hash:  is the output from using the hash-alg algorithm, to hash
               the header including the DKIM-Signature header, and the
               body hash.

   h-headers:  is the list of headers to be signed, as specified in the
               "h" parameter.

   D-SIG:      is the canonicalized DKIM-Signature field itself without
               the signature value portion of the parameter, that is, an
               empty parameter value, with no trailing CRLF.

Notes:

data-hash does not include body-hash (body-hash is already included by virtue of the "bh=" tag in D-SIG). Also, D-SIG should not include the trailing CRLF, unlike the headers in h-headers.

Errata ID: 6076
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: John Levine
Date Reported: 2020-04-01
Verifier Name: Benjamin Kaduk
Date Verified: 2020-04-01

Section .6 says:

      domain-name     = sub-domain 1*("." sub-domain)
                        ; from [RFC5321] Domain,
                        ; excluding address-literal

It should say:

      domain-name     = sub-domain 1*("." sub-domain)
                        ; from [RFC5321] Domain
                        

Notes:

In RFC5321 "domain" does not include address-literal. This mistake was copied from RFC4871
(which referred to the [RFC2821] Domain, which does include address-literal).
This report is just to flag it so we don't put it in the next revision.

Errata ID: 4287
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Phil Griffin (via DCrocker)
Date Reported: 2015-03-04
Verifier Name: Barry Leiba
Date Verified: 2015-03-04

Section 3.6.1 says:

   k= Key type (plain-text; OPTIONAL, default is "rsa").  Signers and
      Verifiers MUST support the "rsa" key type.  The "rsa" key type
      indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey
      (see [RFC3447], Sections 3.1 and A.1.1) is being used in the "p="
      tag.  (Note: the "p=" tag further encodes the value using the
      base64 algorithm.)  Unrecognized key types MUST be ignored.

and in Section 9.1:

   [ITU-X660-1997]
              "Information Technology - ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", 1997.

It should say:

Both instances of "[ITU-X660-1997]" should be "[ITU-X690-1997]"

Notes:

This is just a typo: "660" should be "690". The text of the reference is correct, but the document number is wrong.

Errata ID: 4926
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Simon Ser
Date Reported: 2017-02-07
Verifier Name: Stephen Farrell
Date Verified: 2017-02-14

Section A.2, A.3 says:

DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
     c=simple/simple; q=dns/txt; i=joe@football.example.com;
     h=Received : From : To : Subject : Date : Message-ID;
     bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
     b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
     4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
     KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
     4bmp/YzhwvcubU4=;
Received: from client1.football.example.com  [192.0.2.1]
     by submitserver.example.com with SUBMISSION;
     Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>

It should say:

DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
      c=simple/simple; q=dns/txt; i=joe@football.example.com;
      h=Received : From : To : Subject : Date : Message-ID;
      bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
      b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
      4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
      KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
      4bmp/YzhwvcubU4=;
Received: from client1.football.example.com  [192.0.2.1]
      by submitserver.example.com with SUBMISSION;
      Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>

Notes:

The "simple" header canonicalization doesn't change the header fields in any way.

Folded header fields are missing one space of indentation (they have 5 spaces instead of 6), which makes the verification fail. Note that the plain text version of the RFC adds a prefix of three spaces before each line of text, which must be ignored.

Verifier note: this was disposed of as per the IETF DKIM mailing list discussion.

In section A.3, the indentation is changed again (5 spaces instead of 6 + the "b=" tag has 2 additional spaces of indentation).

Test cases:
- opendkim: https://github.com/cyrusimap/opendkim/blob/ab2934e131cbe670b49f11db9daf8cd1223e3839/libopendkim/tests/t-testdata.h#L74
- go-dkim: https://github.com/emersion/go-dkim/blob/master/verify_test.go#L9

Status: Reported (2)

RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures", September 2011

Source of RFC: dkim (sec)

Errata ID: 5839
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Peter Occil
Date Reported: 2019-08-18

Section 3.4.2 says:

   o  Delete all WSP characters at the end of each unfolded header field
      value.

It should say:

   o  Delete all WSP characters just before the CRLF at the end of 
      each unfolded header field value.

Notes:

A prior step in this section suggests that header field values include the trailing CRLF. If that is the case, then a header field value can't end with WSP, which suggests that this step is incorrectly specified. The correction I give here restores the apparent intent of this step.

Errata ID: 6254
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Dave Crocker
Date Reported: 2020-08-08

Section 5.4 says:


Notes:

The "INFORMATIVE OPERATIONS NOTE" early in Section 5.4 appears to be in conflict with Section 5.4.1. They appear to cover the same issue, namely what header fields to use for the signature, but they seem to give different advice. (Though not formally an erratum, there is also the matter of thinking that what is shown the the recipient is relevant...) /d

Report New Errata