RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 10 records.

Status: Verified (5)

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

Source of RFC: dkim (sec)

Errata ID: 3192

Status: Verified
Type: Technical

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

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: 5137

Status: Verified
Type: Technical

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: 4287

Status: Verified
Type: Editorial

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

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: 3017

Status: Reported
Type: Technical

Reported By: Vernon Tang
Date Reported: 2011-11-05
Edited by: Sean Turner
Date Edited: 2011-11-12

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.

It should say:

   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), which MAY be contained in
      a SubjectPublicKeyInfo (see [RFC5280], Section A.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.

Notes:

The procedure in Appendix C results in a public key in SubjectPublicKeyInfo format. Accordingly, most current implementations will accept such keys. Furthermore, it is trivial to distinguish whether a key is encapsulated in a SubjectPublicKeyInfo.

Errata ID: 5070

Status: Reported
Type: Technical

Reported By: Chris Newman
Date Reported: 2017-07-15

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.

Status: Held for Document Update (1)

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

Source of RFC: dkim (sec)

Errata ID: 4875

Status: Held for Document Update
Type: Editorial

Reported By: Emiel Bruijntjes
Date Reported: 2016-12-01

Section 3.5 says:

The header field text itself must encode the vertical bar
("|", %x7C) character (i.e., vertical bars in the "z=" text are
meta-characters, and any actual vertical bar characters in a
copied header field must be encoded).  Note that all whitespace
must be encoded, including whitespace between the colon and the
header field value.  After encoding, FWS MAY be added at arbitrary
locations in order to avoid excessively long lines; such
whitespace is NOT part of the value of the header field and MUST
be removed before decoding.

It should say:

The header field value itself must encode the vertical bar
("|", %x7C) character (i.e., vertical bars in the "z=" text are
meta-characters, and any actual vertical bar characters in a
copied header field must be encoded).  Note that all whitespace
must be encoded, including whitespace between the colon and the
header field value.  After encoding, FWS MAY be added at arbitrary
locations inside the header field value in order to avoid 
excessively long lines; such whitespace is NOT part of the value 
of the header field and MUST be removed before decoding. FWS MAY NOT
be added to the header field name.

Notes:

The original text is confusing on whether FWS may be added to just the header field values or to both the header field names and header field values. The ABNF suggests that it is just allowed inside the values, but we've seen in practice that this whitespace is also added to the field names.

Further more, the use of the three terms "header field name", "header field value" and "header field text" is confusing. It is better to stick with just "header field name" and "header field value".

Status: Rejected (2)

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

Source of RFC: dkim (sec)

Errata ID: 3758

Status: Rejected
Type: Technical

Reported By: Majid Tajamolian & Nazilla Karkon
Date Reported: 2013-10-20
Rejected by: Barry Leiba
Date Rejected: 2013-10-20

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

It should say:

v= Version of the DKIM key record (plain-text; RECOMMENDED, default
      is "1").  If specified, this tag MUST be set to "1"
      (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, "1" is not the same as
      "1.0".

Notes:

The "DKIM" prefix in the version field is unnecessary.
for example the followings are snipped from an actual email via gmail.com:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:from:date:message-id:subject:to:content-type;
bh=46j07/8gDec8jTto/znsrAKiXDj6YJ7Wa2DCoZuhwXc=;
b=h6SViP6DcHgPwydJD6aztqyKd0UmCN3SdwmqZd0uCHmqrprphjN8qQ8AnBDhbwDhAa
DfHIDS8RSegELKtzsp95u+DnIFg1uNhIukKVpGT+9MqxfCSAFk7WpMe2O/2gcLruilTe
MxkKJ29s64NGevYewKtI8s73xHmbzD1NFH9ugdow8i9E16kgQ+vAx56qvbFTBwdEEw8I
6Bteu3tXEsYYbU/9Akm2GXS+6PFiDSbv47u3EmhRQIOK3e8DvcobrpicjL7vUwBCpQuf
J/c+Acdq4GZQoMoG9imzku0K2o0w33CZ1xUR1bARJKCVaJfWeHiEMQ2OJ9A6ZtqpyK0z
1Ftg==
--VERIFIER NOTES--
The reporters are confused. The text in Section 3.6.1 is about the key records in the DNS, and the document is correct. Section 3.5 is where the dkim-signature header field is described (and that is also correct).

Errata ID: 3759

Status: Rejected
Type: Editorial

Reported By: Majid Tajamolian & Nazila Karkon
Date Reported: 2013-10-20
Rejected by: Barry Leiba
Date Rejected: 2013-10-20

Section 3.6.1. says:

   h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
      allowing all algorithms).  A colon-separated list of hash
      algorithms that might be used.  Unrecognized algorithms MUST be
      ignored.  Refer to Section 3.3 for a discussion of the hash
      algorithms implemented by Signers and Verifiers.  The set of
      algorithms listed in this tag in each record is an operational
      choice made by the Signer.

It should say:

   a= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
      allowing all algorithms).  A colon-separated list of hash
      algorithms that might be used.  Unrecognized algorithms MUST be
      ignored.  Refer to Section 3.3 for a discussion of the hash
      algorithms implemented by Signers and Verifiers.  The set of
      algorithms listed in this tag in each record is an operational
      choice made by the Signer.

Notes:

The correct tag is "a=" for algorithms not "h=". The latter is used for the "List of Included Headers in the Signature"
--VERIFIER NOTES--
The reporters are confused. The text in Section 3.6.1 is about the key records in the DNS, and the document is correct. Section 3.5 is where the dkim-signature header field is described (and that is also correct).

Report New Errata



Search RFCs
Advanced Search
×