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