RFC Errata
Found 21 records.
Status: Verified (9)
RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures", September 2011
Note: This RFC has been updated by RFC 8301, RFC 8463, RFC 8553, RFC 8616
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: 5839
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2019-08-18
Verifier Name: Murray Kucherawy
Date Verified: 2021-12-02
Section 3.4.2 says:
o Delete all WSP characters at the end of each unfolded header field
value.
It should say:
o Delete the SP character, if present, at the end of each unfolded
header field value before its final CRLF
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.
[MSK: The corrected text was modified after discussion on the WG mailing list.]
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
Note: This RFC has been updated by RFC 8301, RFC 8463, RFC 8553, RFC 8616
Source of RFC: dkim (sec)
Errata ID: 6674
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Christian Böhme
Date Reported: 2021-09-01
Section Appendix C says:
This results in the file rsa.public containing the key information
similar to this:
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM
oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R
tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI
MmPSPDdQPNUYckcQ2QIDAQAB
-----END PUBLIC KEY-----
This public-key data (without the BEGIN and END tags) is placed in
the DNS:
$ORIGIN _domainkey.example.org.
brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ"
"KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt"
"IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v"
"/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi"
"tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB")
It should say:
This results in the file rsa.public containing the key information
similar to this (long output lines truncated):
openssl asn1parse -i -inform PEM -in rsa.public
0:d=0 hl=3 l= 159 cons: SEQUENCE
3:d=1 hl=2 l= 13 cons: SEQUENCE
5:d=2 hl=2 l= 9 prim: OBJECT :rsaEncryption
16:d=2 hl=2 l= 0 prim: NULL
18:d=1 hl=3 l= 141 prim: BIT STRING
openssl asn1parse -i -inform PEM -in rsa.public -strparse 18
0:d=0 hl=3 l= 137 cons: SEQUENCE
3:d=1 hl=3 l= 129 prim: INTEGER :F02113FF502DD206C126…
135:d=1 hl=2 l= 3 prim: INTEGER :010001
The result of
openssl asn1parse -i -inform PEM -in rsa.public -offset 22 -out /dev/stdout -noout | openssl base64
is then placed in the DNS:
$ORIGIN _domainkey.example.org.
brisbane IN TXT ("v=DKIM1; p=MIGJAoGBAPAhE/9QLdIGwSYapn1klbf8OQ"
"ygZ4udCDV9afv/Ni0jE3ZKcUKPE4Iob2/dviNh9xM2HmK"
"NKyrrfW4Ei0truh36/9G10LZTMnWVZP3jupH5FxpzaBu2"
"j80yonR/N9WMfg64qGK11j21/qZzAaNo0FxZOggyY9I8N"
"1A81RhyRxDZAgMBAAE=")
Notes:
Empirical evidence suggests that MSPs have taken the command lines in
Appendix C literally, and, by doing so, have deviated from the specification
laid out in Section 3.6.1. for the k= and p= tags.
Specifically, the openssl rsa command, used with its -pubout option
as demonstrated in Appendix C, produces a SubjectPublicKeyInfo-typed result
instead of a RSAPublicKey-typed one. It does so for both DER and PEM
arguments to the -outform option.
What is more, had Section 3.6.1., p= tag, specified a base64-encoded
SubjectPublicKeyInfo-typed value instead of a RSAPublicKey-typed one,
Section 3.6.1., k= tag, could have been dispensed of entirely, since
the SubjectPublicKeyInfo type contains an AlgorithmIdentifier-typed
attribute for that purpose.
That indeed an RSAPublicKey-typed result for the p= tag was intended
by RFC 6376 can be confirmed by comparison with RFC 8463, Section 4.2.,
which specifies that a "raw" Ed25519 public key be used, instead of
a SubjectPublicKeyInfo-typed one such as defined in RFC 8410,
Section 4. Subject Public Key Fields.
The Corrected Text uses the same public key data from the Original Text.
Errata ID: 7001
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ori Bernstein
Date Reported: 2022-06-21
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.
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] SubjectPublicKeyInfo
(see [RFC5280], Section 4.1) is being used in the "p="
tag.
Notes:
The format specified for RSA keys is not what is used
either in the wild, or in the examples in this RFC.
The current citation for the RSAPublicKey format is
listed below for reference:
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e
}
Taking the example public key in this RFC document:
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM
oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R
tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI
MmPSPDdQPNUYckcQ2QIDAQAB
-----END PUBLIC KEY-----
We can decode it as asn.1, and see that it is not in the format
specified:
$ openssl asn1parse -i -inform pem -in /home/ori/ykey.pem
0:d=0 hl=3 l= 159 cons: SEQUENCE
3:d=1 hl=2 l= 13 cons: SEQUENCE
5:d=2 hl=2 l= 9 prim: OBJECT :rsaEncryption
16:d=2 hl=2 l= 0 prim: NULL
18:d=1 hl=3 l= 141 prim: BIT STRING
The openssl documentation unhelpfully says that it's generated
in the "traditional SSLEay format". Poking around, that seems
to correspond to SubjectPublicKeyInfo in RFC5280:
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
When generating a key that conforms to the RSAPublicKey
encoding, multiple sites (including gmail) reject the key,
claiming a failure to parse the tag -- this is also the
error that openssl has when attempting to parse an RSA
public key in this format; for example:
-----BEGIN PUBLIC KEY-----
MIGJAoGBAOPkeIi7+kBDwxOlfJFeWygu5Txt43ddLdY8AfWxLIHtQObNhgsxuaWh
UUhlftnJWcafJg6V8HVyvd4i+3D0l/PLHu89bIkGnH0ts/weIvQJ+Rx/hVZtS/H1
vkHRmiPnO5gaDi/jvfAFWcG4BiJgkEcUovKbmWAxYzGBqe/8um23AgMBAAE=
-----END PUBLIC KEY-----
$ openssl asn1parse -i -inform pem -in /home/ori/key.pem
0:d=0 hl=3 l= 137 cons: SEQUENCE
3:d=1 hl=3 l= 129 prim: INTEGER :E3E47888BBFA404·.
135:d=1 hl=2 l= 3 prim: INTEGER :010001
$ openssl rsa -pubin -in /home/ori/key.pem -text
unable to load Public Key
140290635060544:error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag:../crypto/asn1/tasn_dec.c:1149:
140290635060544:error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:309:Type=X509_ALGOR
140290635060544:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:646:Field=algor, Type=X509_PUBKEY
140290635060544:error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib:../crypto/pem/pem_oth.c:33:
While in theory it would be better to fix the examples,
I think that ship has sailed, and it's better instead
to fix the citation in the specification.
Status: Held for Document Update (4)
RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures", September 2011
Note: This RFC has been updated by RFC 8301, RFC 8463, RFC 8553, RFC 8616
Source of RFC: dkim (sec)
Errata ID: 6254
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Dave Crocker
Date Reported: 2020-08-08
Held for Document Update by: Murray Kucherawy
Date Held: 2021-12-02
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
Errata ID: 6769
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ale Vesely
Date Reported: 2021-12-01
Held for Document Update by: Murray Kucherawy
Date Held: 2021-12-02
Section 8.2 says:
An example of such an attack includes altering the MIME structure, exploiting lax HTML parsing in the MUA, and defeating duplicate message detection algorithms.
It should say:
In case of MIME structures, the value of l= should cover all of the body, including the terminating boundary and the epilogue, so that altering the structure is not feasible. In any case, if l= is set and Content-Type is not signed, an attacker can replace it with a multipart type and thus relegate the original body to the role of a MIME preamble.
Notes:
Duplicate message detection algorithms should consider Message-ID. When they compare the body, they should be sophisticated enough to recognize specific key fields, for example to avoid accumulating duplicate values of financial transactions.
Errata ID: 3017
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vernon Tang
Date Reported: 2011-11-05
Held for Document Update by: Barry Leiba
Date Held: 2019-04-30
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: 4875
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
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 (6)
RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures", September 2011
Note: This RFC has been updated by RFC 8301, RFC 8463, RFC 8553, RFC 8616
Source of RFC: dkim (sec)
Errata ID: 3758
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
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: 5551
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Borislav Petrov
Date Reported: 2018-11-09
Rejected by: Barry Leiba
Date Rejected: 2019-04-30
Section 6.3. says:
If an MTA does wish to reject such messages during an SMTP session (for example, when communicating with a peer who, by prior agreement, agrees to only send signed messages), and a signature is missing or does not verify, the handling MTA SHOULD use a 550/5.7.x reply code. Where the Verifier is integrated within the MTA and it is not possible to fetch the public key, perhaps because the key server is not available, a temporary failure message MAY be generated using a 451/4.7.5 reply code, such as: 451 4.7.5 Unable to verify signature - key server unavailable Temporary failures such as inability to access the key server or other external service are the only conditions that SHOULD use a 4xx SMTP reply code.
Notes:
This contradicts RFC5321 which says:
...a relay SMTP has no need to inspect or
act upon the header section or body of the message data and MUST NOT
do so except to add its own "Received:" header field...
--VERIFIER NOTES--
There is nothing in the cited text above that suggests modifications to the message. The text only talks about which SMTP reply codes to use.
Errata ID: 5713
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Victor Shrubowich
Date Reported: 2019-04-30
Rejected by: Benjamin Kaduk
Date Rejected: 2019-04-30
Section 2.8 says:
FWS = [*WSP CRLF] 1*WSP
It should say:
FWS = [*WSP] CRLF 1*WSP
Notes:
In the ABNF RFC ([RFC5234]), section 3.8 states "Square brackets enclose an optional element sequence".
CRLF is required for folding. However, the CRLF in the FWS rule is shown inside the square brackets, which would make it optional. It should not be inside the square brackets.
(See Errata ID 5712 for FWS in [RFC5322], which is referenced at the end of section 2.8.)
--VERIFIER NOTES--
As noted by Dave Crocker, Folding White Space is a construct that permits a newline but does not require it -- only whitespace of some form is required to be present in order to match, not a specific kind of whitespace. The present construction, as corresponds to RFC 5322, is as intended.
Errata ID: 7862
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Steffen Nurpmeso
Date Reported: 2024-03-21
Rejected by: Murray Kucherawy
Date Rejected: 2024-03-22
Section 3.4.2 says:
[..]
It should say:
[insert after item 2] Due to de-facto implementation practice, the term WSP of the following two items, as well as in the part that refers to after the separating colon (the field body) in the third, has to be interpreted differently, and must include all US-ASCII whitespace characters, namely %d9 (HT), %d10 (LF), %d11 (VT), %d12 (FF), %d12 (CR) as well as %d32 (SP) [?](the isspace(3) set of characters in the ISO C "C" locale)[/?]
Notes:
As written.
The behaviour *could* originate in a partial misunderstanding of the Sendmail milter protocol, which is often used to implement DKIM; this protocol *may* send header continuation lines separated by lone LF bytes, instead of CRLF.
(Thanks to Claus Assmann of esmtp.org for this in-between-the-lines reading.)
--VERIFIER NOTES--
Withdrawn by submitter.
Errata ID: 3759
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
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).
Errata ID: 5260
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ale
Date Reported: 2018-02-08
Rejected by: Barry Leiba
Date Rejected: 2019-04-30
Section 3.5 says:
It should say:
DKIM-Signature = "DKIM-Signature:" tag-list
Notes:
A formal definition is needed to make it explicit that this header field name is case insensitive, like all the other header field names.
--VERIFIER NOTES--
Header field names are case-insensitive, in general; there is neither need nor desire to repeat that in the DKIM spec.