RFC Errata
Found 16 records.
Status: Verified (7)
RFC 4871, "DomainKeys Identified Mail (DKIM) Signatures", May 2007
Note: This RFC has been obsoleted by RFC 6376
Note: This RFC has been updated by RFC 5672
Source of RFC: dkim (sec)
Errata ID: 1376
Status: Verified
Type: Technical
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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)
RFC 4871, "DomainKeys Identified Mail (DKIM) Signatures", May 2007
Note: This RFC has been obsoleted by RFC 6376
Note: This RFC has been updated by RFC 5672
Source of RFC: dkim (sec)
Errata ID: 1380
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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)
RFC 4871, "DomainKeys Identified Mail (DKIM) Signatures", May 2007
Note: This RFC has been obsoleted by RFC 6376
Note: This RFC has been updated by RFC 5672
Source of RFC: dkim (sec)
Errata ID: 1385
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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.