RFC Errata
Found 11 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.