draft-ietf-dkim-base-04.txt   draft-ietf-dkim-base-05.txt 
DKIM E. Allman DKIM E. Allman
Internet-Draft Sendmail, Inc. Internet-Draft Sendmail, Inc.
Expires: January 16, 2007 J. Callas Expires: February 24, 2007 J. Callas
PGP Corporation PGP Corporation
M. Delany M. Delany
M. Libbey M. Libbey
Yahoo! Inc Yahoo! Inc
J. Fenton J. Fenton
M. Thomas M. Thomas
Cisco Systems, Inc. Cisco Systems, Inc.
July 15, 2006 August 23, 2006
DomainKeys Identified Mail (DKIM) Signatures DomainKeys Identified Mail (DKIM) Signatures
draft-ietf-dkim-base-04 draft-ietf-dkim-base-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 16, 2007. This Internet-Draft will expire on February 24, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
DomainKeys Identified Mail (DKIM) defines a domain-level DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email using public-key cryptography and authentication framework for email using public-key cryptography and
key server technology to permit verification of the source and key server technology to permit verification of the source and
skipping to change at page 3, line 35 skipping to change at page 3, line 35
3.7 Computing the Message Hashes . . . . . . . . . . . . . . . 30 3.7 Computing the Message Hashes . . . . . . . . . . . . . . . 30
3.8 Signing by Parent Domains . . . . . . . . . . . . . . . . 32 3.8 Signing by Parent Domains . . . . . . . . . . . . . . . . 32
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . 32 4. Semantics of Multiple Signatures . . . . . . . . . . . . . . 32
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 32 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 32
5.1 Determine if the Email Should be Signed and by Whom . . . 33 5.1 Determine if the Email Should be Signed and by Whom . . . 33
5.2 Select a private-key and corresponding selector 5.2 Select a private-key and corresponding selector
information . . . . . . . . . . . . . . . . . . . . . . . 33 information . . . . . . . . . . . . . . . . . . . . . . . 33
5.3 Normalize the Message to Prevent Transport Conversions . . 34 5.3 Normalize the Message to Prevent Transport Conversions . . 34
5.4 Determine the header fields to Sign . . . . . . . . . . . 34 5.4 Determine the header fields to Sign . . . . . . . . . . . 34
5.5 Compute the Message Hash and Signature . . . . . . . . . . 36 5.5 Compute the Message Hash and Signature . . . . . . . . . . 36
5.6 Insert the DKIM-Signature header field . . . . . . . . . . 36 5.6 Insert the DKIM-Signature header field . . . . . . . . . . 37
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 37 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 37
6.1 Extract Signatures from the Message . . . . . . . . . . . 37 6.1 Extract Signatures from the Message . . . . . . . . . . . 38
6.2 Communicate Verification Results . . . . . . . . . . . . . 43 6.2 Communicate Verification Results . . . . . . . . . . . . . 43
6.3 Interpret Results/Apply Local Policy . . . . . . . . . . . 43 6.3 Interpret Results/Apply Local Policy . . . . . . . . . . . 43
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 44 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 45
7.1 DKIM-Signature Tag Specifications . . . . . . . . . . . . 44 7.1 DKIM-Signature Tag Specifications . . . . . . . . . . . . 45
7.2 DKIM-Signature Query Method Registry . . . . . . . . . . . 45 7.2 DKIM-Signature Query Method Registry . . . . . . . . . . . 45
7.3 DKIM-Signature Canonicalization Registry . . . . . . . . . 45 7.3 DKIM-Signature Canonicalization Registry . . . . . . . . . 46
7.4 _domainkey DNS TXT Record Tag Specifications . . . . . . . 46 7.4 _domainkey DNS TXT Record Tag Specifications . . . . . . . 46
7.5 DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 47 7.5 DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 47
7.6 DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 47 7.6 DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 47
8. Security Considerations . . . . . . . . . . . . . . . . . . 47 7.7 DKIM Service Types Registry . . . . . . . . . . . . . . . 48
8.1 Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 47 7.8 DKIM Selector Flags Registry . . . . . . . . . . . . . . . 48
8.2 Misappropriated Private Key . . . . . . . . . . . . . . . 48 8. Security Considerations . . . . . . . . . . . . . . . . . . 49
8.3 Key Server Denial-of-Service Attacks . . . . . . . . . . . 49 8.1 Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 49
8.4 Attacks Against DNS . . . . . . . . . . . . . . . . . . . 49 8.2 Misappropriated Private Key . . . . . . . . . . . . . . . 49
8.5 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 50 8.3 Key Server Denial-of-Service Attacks . . . . . . . . . . . 50
8.6 Limits on Revoking Keys . . . . . . . . . . . . . . . . . 51 8.4 Attacks Against DNS . . . . . . . . . . . . . . . . . . . 51
8.7 Intentionally malformed Key Records . . . . . . . . . . . 51 8.5 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 51
8.8 Intentionally Malformed DKIM-Signature header fields . . . 51 8.6 Limits on Revoking Keys . . . . . . . . . . . . . . . . . 52
8.9 Information Leakage . . . . . . . . . . . . . . . . . . . 51 8.7 Intentionally malformed Key Records . . . . . . . . . . . 52
8.10 Remote Timing Attacks . . . . . . . . . . . . . . . . . 51 8.8 Intentionally Malformed DKIM-Signature header fields . . . 52
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 8.9 Information Leakage . . . . . . . . . . . . . . . . . . . 52
9.1 Normative References . . . . . . . . . . . . . . . . . . . 52 8.10 Remote Timing Attacks . . . . . . . . . . . . . . . . . 53
9.2 Informative References . . . . . . . . . . . . . . . . . . 52 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53 9.1 Normative References . . . . . . . . . . . . . . . . . . . 53
A. Example of Use (INFORMATIVE) . . . . . . . . . . . . . . . . 54 9.2 Informative References . . . . . . . . . . . . . . . . . . 53
A.1 The user composes an email . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 54
A.2 The email is signed . . . . . . . . . . . . . . . . . . . 55 A. Example of Use (INFORMATIVE) . . . . . . . . . . . . . . . . 56
A.3 The email signature is verified . . . . . . . . . . . . . 56 A.1 The user composes an email . . . . . . . . . . . . . . . . 56
B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . . . . . 57 A.2 The email is signed . . . . . . . . . . . . . . . . . . . 56
B.1 Simple Message Forwarding . . . . . . . . . . . . . . . . 57 A.3 The email signature is verified . . . . . . . . . . . . . 57
B.2 Outsourced Business Functions . . . . . . . . . . . . . . 57 B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . . . . . 58
B.3 PDAs and Similar Devices . . . . . . . . . . . . . . . . . 57 B.1 Simple Message Forwarding . . . . . . . . . . . . . . . . 58
B.4 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 58 B.2 Outsourced Business Functions . . . . . . . . . . . . . . 58
B.5 Affinity Addresses . . . . . . . . . . . . . . . . . . . . 58 B.3 PDAs and Similar Devices . . . . . . . . . . . . . . . . . 59
B.6 Third-party Message Transmission . . . . . . . . . . . . . 59 B.4 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 59
B.7 SMTP Servers for Roaming Users . . . . . . . . . . . . . . 59 B.5 Affinity Addresses . . . . . . . . . . . . . . . . . . . . 60
C. Creating a public key (INFORMATIVE) . . . . . . . . . . . . 59 B.6 Third-party Message Transmission . . . . . . . . . . . . . 60
D. MUA Considerations . . . . . . . . . . . . . . . . . . . . . 61 B.7 SMTP Servers for Roaming Users . . . . . . . . . . . . . . 61
E. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 62 C. Creating a public key (INFORMATIVE) . . . . . . . . . . . . 61
F. Edit History . . . . . . . . . . . . . . . . . . . . . . . . 62 D. MUA Considerations . . . . . . . . . . . . . . . . . . . . . 63
F.1 Changes since -ietf-03 version . . . . . . . . . . . . . . 62 E. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 63
F.2 Changes since -ietf-02 version . . . . . . . . . . . . . . 63 F. Edit History . . . . . . . . . . . . . . . . . . . . . . . . 64
F.3 Changes since -ietf-01 version . . . . . . . . . . . . . . 64 F.1 Changes since -ietf-04 version . . . . . . . . . . . . . . 64
F.4 Changes since -ietf-00 version . . . . . . . . . . . . . . 65 F.2 Changes since -ietf-03 version . . . . . . . . . . . . . . 64
F.5 Changes since -allman-01 version . . . . . . . . . . . . . 66 F.3 Changes since -ietf-02 version . . . . . . . . . . . . . . 66
F.6 Changes since -allman-00 version . . . . . . . . . . . . . 66 F.4 Changes since -ietf-01 version . . . . . . . . . . . . . . 67
Intellectual Property and Copyright Statements . . . . . . . 67 F.5 Changes since -ietf-00 version . . . . . . . . . . . . . . 67
F.6 Changes since -allman-01 version . . . . . . . . . . . . . 68
F.7 Changes since -allman-00 version . . . . . . . . . . . . . 68
Intellectual Property and Copyright Statements . . . . . . . 69
1. Introduction 1. Introduction
[[Note: text in double square brackets (such as this text) will be [[Note: text in double square brackets (such as this text) will be
deleted before publication.]] deleted before publication.]]
DomainKeys Identified Mail (DKIM) defines a mechanism by which email DomainKeys Identified Mail (DKIM) defines a mechanism by which email
messages can be cryptographically signed, permitting a signing domain messages can be cryptographically signed, permitting a signing domain
to claim responsibility for the introduction of a message into the to claim responsibility for the introduction of a message into the
mail stream. Message recipients can verify the signature by querying mail stream. Message recipients can verify the signature by querying
skipping to change at page 7, line 24 skipping to change at page 7, line 24
verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs. verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs.
In most cases it is expected that verifiers will be close to an end In most cases it is expected that verifiers will be close to an end
user (reader) of the message or some consuming agent such as a user (reader) of the message or some consuming agent such as a
mailing list exploder. mailing list exploder.
2.3 White Space 2.3 White Space
There are three forms of white space: There are three forms of white space:
o WSP represents simple white space, i.e., a space or a tab o WSP represents simple white space, i.e., a space or a tab
character, and is inherited from[RFC2822]. character.
o SWSP is streaming white space, defined as WSP plus the CR and LF o SWSP is streaming white space, defined as WSP plus CRLF.
characters.
o FWS, also from [RFC2822], is folding white space. It allows o FWS is folding white space. It allows multiple lines separated by
multiple lines separated by CRLF followed by at least one white CRLF followed by at least one white space, to be joined.
space, to be joined.
The formal ABNF for SWSP is: The formal ABNF SWSP and FWS is:
SWSP = CR / LF / WSP ; streaming white space SWSP = WSP / CRLF ; streaming white space
FWSP = ([*WSP CRLF] 1*WSP)
The definition of FWS is identical to that in [RFC2822] except for
the exclusion of obs-FWS. WSP is inherited from [RFC4234].
2.4 Common ABNF Tokens 2.4 Common ABNF Tokens
The following ABNF tokens are used elsewhere in this document. The following ABNF tokens are used elsewhere in this document.
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ]
base64string = 1*(ALPHA / DIGIT / "+" / "/" / "=" / SWSP) base64string = 1*(ALPHA / DIGIT / "+" / "/" / "=" / SWSP)
2.5 Imported ABNF Tokens 2.5 Imported ABNF Tokens
skipping to change at page 8, line 36 skipping to change at page 8, line 37
o "qp-section" (a single line of quoted-printable-encoded text) o "qp-section" (a single line of quoted-printable-encoded text)
o "hex-octet" (a quoted-printable encoded octet) o "hex-octet" (a quoted-printable encoded octet)
INFORMATIVE NOTE: Be aware that the ABNF in RFC 2045 does not INFORMATIVE NOTE: Be aware that the ABNF in RFC 2045 does not
obey the rules of RFC 4234 and must be interpreted accordingly, obey the rules of RFC 4234 and must be interpreted accordingly,
particularly as regards case folding. particularly as regards case folding.
Other tokens not defined herein are imported from [RFC4234]. These Other tokens not defined herein are imported from [RFC4234]. These
are intuitive primitives such as SP, ALPHA, CRLF, etc. are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF,
etc.
2.6 DKIM-Quoted-Printable 2.6 DKIM-Quoted-Printable
The DKIM-Quoted-Printable encoding syntax resembles that described in The DKIM-Quoted-Printable encoding syntax resembles that described in
Quoted-Printable [RFC2045] section 6.7: any character MAY be encoded Quoted-Printable [RFC2045] section 6.7: any character MAY be encoded
as an "=" followed by two hexadecimal digits from the alphabet as an "=" followed by two hexadecimal digits from the alphabet
"0123456789ABCDEF" (no lower case characters permitted) representing "0123456789ABCDEF" (no lower case characters permitted) representing
the hexadecimal-encoded integer value of that character. All control the hexadecimal-encoded integer value of that character. All control
characters (those with values < %x20), eight-bit characters (values > characters (those with values < %x20), eight-bit characters (values >
%x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon %x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon
skipping to change at page 14, line 37 skipping to change at page 14, line 37
tolerates common modifications such as white-space replacement and tolerates common modifications such as white-space replacement and
header field line re-wrapping. A signer MAY specify either algorithm header field line re-wrapping. A signer MAY specify either algorithm
for header or body when signing an email. If no canonicalization for header or body when signing an email. If no canonicalization
algorithm is specified by the signer, the "simple" algorithm defaults algorithm is specified by the signer, the "simple" algorithm defaults
for both header and body. Verifiers MUST implement both for both header and body. Verifiers MUST implement both
canonicalization algorithms. Note that the header and body may use canonicalization algorithms. Note that the header and body may use
different canonicalization algorithms. Further canonicalization different canonicalization algorithms. Further canonicalization
algorithms MAY be defined in the future; verifiers MUST ignore any algorithms MAY be defined in the future; verifiers MUST ignore any
signatures that use unrecognized canonicalization algorithms. signatures that use unrecognized canonicalization algorithms.
[[WORKING GROUP DISCUSSION POINT: If a message is transmitted [[NON-NORMATIVE DISCUSSION POINT: If a message is transmitted
using CHUNKING (that is, BDAT instead of the DATA command) and using CHUNKING (that is, BDAT instead of the DATA command) and
BODY=BINARYMIME [RFC3030] then the body should be treated as a BODY=BINARYMIME [RFC3030] then the body should be treated as a
binary stream, and no canonicalization whatsoever should be done. binary stream, and no canonicalization whatsoever should be done.
Do we want to leave this for the future, say that canonicalization Do we want to leave this for the future, say that canonicalization
is ignored in this circumstance, or add a third "binary" body is ignored in this circumstance, or add a third "binary" body
canonicalization algorithm? Or something else, of course.]] canonicalization algorithm? Or something else, of course.]]
Canonicalization simply prepares the email for presentation to the Canonicalization simply prepares the email for presentation to the
signing or verification algorithm. It MUST NOT change the signing or verification algorithm. It MUST NOT change the
transmitted data in any way. Canonicalization of header fields and transmitted data in any way. Canonicalization of header fields and
skipping to change at page 16, line 19 skipping to change at page 16, line 19
o Ignores all white space at the end of lines. Implementations MUST o Ignores all white space at the end of lines. Implementations MUST
NOT remove the CRLF at the end of the line. NOT remove the CRLF at the end of the line.
o Reduces all sequences of WSP within a line to a single SP o Reduces all sequences of WSP within a line to a single SP
character. character.
o Ignores all empty lines at the end of the message body. "Empty o Ignores all empty lines at the end of the message body. "Empty
line" is defined in Section 3.4.3. line" is defined in Section 3.4.3.
[[WORKING GROUP DISCUSSION POINT (ISSUE 1326): Mike Thomas has [[NON-NORMATIVE DISCUSSION POINT (ISSUE 1326): Mike Thomas has
found bare CRs in the wild that are getting converted to CRLF by found bare CRs in the wild that are getting converted to CRLF by
some MTAs and thus breaking signatures. Shall we (a) drop some MTAs and thus breaking signatures. Shall we (a) drop
"relaxed" until we can figure out how to do it right and then put "relaxed" until we can figure out how to do it right and then put
it in as an extension, (b) change "relaxed" to handle this case, it in as an extension, (b) change "relaxed" to handle this case,
probably by having it convert bare CR and LF to CRLF, or (c) probably by having it convert bare CR and LF to CRLF, or (c)
something else?]] something else?]]
3.4.5 Body Length Limits 3.4.5 Body Length Limits
A body length count MAY be specified to limit the signature A body length count MAY be specified to limit the signature
skipping to change at page 17, line 30 skipping to change at page 17, line 30
unsigned. unsigned.
Signers wishing to ensure that no modification of any sort can occur Signers wishing to ensure that no modification of any sort can occur
should specify the "simple" canonicalization algorithm for both should specify the "simple" canonicalization algorithm for both
header and body and omit the body length count. header and body and omit the body length count.
3.4.6 Canonicalization Examples (INFORMATIVE) 3.4.6 Canonicalization Examples (INFORMATIVE)
(In the following examples, actual white space is used only for (In the following examples, actual white space is used only for
clarity. The actual input and output text is designated using clarity. The actual input and output text is designated using
bracketed descriptors: "<SP>" for a space character, "<TAB>" for a bracketed descriptors: "<SP>" for a space character, "<HTAB>" for a
tab character, and "<CRLF>" for a carriage-return/line-feed sequence. tab character, and "<CRLF>" for a carriage-return/line-feed sequence.
For example, "X <SP> Y" and "X<SP>Y" represent the same three For example, "X <SP> Y" and "X<SP>Y" represent the same three
characters.) characters.)
Example 1: A message reading: Example 1: A message reading:
A: <SP> X <CRLF> A: <SP> X <CRLF>
B <SP> : <SP> Y <TAB><CRLF> B <SP> : <SP> Y <HTAB><CRLF>
<TAB> Z <SP><SP><CRLF> <HTAB> Z <SP><SP><CRLF>
<CRLF> <CRLF>
<SP> C <SP><CRLF> <SP> C <SP><CRLF>
D <SP><TAB><SP> E <CRLF> D <SP><HTAB><SP> E <CRLF>
<CRLF> <CRLF>
<CRLF> <CRLF>
when canonicalized using relaxed canonicalization for both header and when canonicalized using relaxed canonicalization for both header and
body results in a header reading: body results in a header reading:
a:X <CRLF> a:X <CRLF>
b:Y <SP> Z <CRLF> b:Y <SP> Z <CRLF>
and a body reading: and a body reading:
<SP> C <CRLF> <SP> C <CRLF>
D <SP> E <CRLF> D <SP> E <CRLF>
Example 2: The same message canonicalized using simple Example 2: The same message canonicalized using simple
canonicalization for both header and body results in a header canonicalization for both header and body results in a header
reading: reading:
A: <SP> X <CRLF> A: <SP> X <CRLF>
B <SP> : <SP> Y <TAB><CRLF> B <SP> : <SP> Y <HTAB><CRLF>
<TAB> Z <SP><SP><CRLF> <HTAB> Z <SP><SP><CRLF>
and a body reading: and a body reading:
<SP> C <SP><CRLF> <SP> C <SP><CRLF>
D <SP><TAB><SP> E <CRLF> D <SP><HTAB><SP> E <CRLF>
Example 3: When processed using relaxed header canonicalization and Example 3: When processed using relaxed header canonicalization and
simple body canonicalization, the canonicalized version has a header simple body canonicalization, the canonicalized version has a header
of: of:
a:X <CRLF> a:X <CRLF>
b:Y <SP> Z <CRLF> b:Y <SP> Z <CRLF>
and a body reading: and a body reading:
<SP> C <SP><CRLF> <SP> C <SP><CRLF>
D <SP><TAB><SP> E <CRLF> D <SP><HTAB><SP> E <CRLF>
3.5 The DKIM-Signature header field 3.5 The DKIM-Signature header field
The signature of the email is stored in the "DKIM-Signature:" header The signature of the email is stored in the "DKIM-Signature:" header
field. This header field contains all of the signature and key- field. This header field contains all of the signature and key-
fetching data. The DKIM-Signature value is a tag-list as described fetching data. The DKIM-Signature value is a tag-list as described
in Section 3.2. in Section 3.2.
The "DKIM-Signature:" header field SHOULD be treated as though it The "DKIM-Signature:" header field SHOULD be treated as though it
were a trace header field as defined in section 3.6 of [RFC2822], and were a trace header field as defined in section 3.6 of [RFC2822], and
skipping to change at page 19, line 16 skipping to change at page 19, line 16
"=3B"; intuitively, this is one line of quoted-printable encoded "=3B"; intuitively, this is one line of quoted-printable encoded
text. Tags described as dkim-quoted-printable are as defined in text. Tags described as dkim-quoted-printable are as defined in
Section 2.6. Section 2.6.
Tags on the DKIM-Signature header field along with their type and Tags on the DKIM-Signature header field along with their type and
requirement status are shown below. Unrecognized tags MUST be requirement status are shown below. Unrecognized tags MUST be
ignored. ignored.
v= Version (MUST be included). This tag defines the version of this v= Version (MUST be included). This tag defines the version of this
specification that applies to the signature record. It MUST have specification that applies to the signature record. It MUST have
the value 0.4. the value 0.5.
ABNF: ABNF:
sig-v-tag = %x76 [FWS] "=" [FWS] "0.4" sig-v-tag = %x76 [FWS] "=" [FWS] "0.5"
INFORMATIVE NOTE: DKIM-Signature version numbers are INFORMATIVE NOTE: DKIM-Signature version numbers are
expected to increase arithmetically as new versions of this expected to increase arithmetically as new versions of this
specification are released. specification are released.
[[INFORMATIVE NOTE: Upon publication, this version number [[INFORMATIVE NOTE: Upon publication, this version number
should be changed to "1", and this note should be deleted.]] should be changed to "1", and this note should be deleted.]]
a= The algorithm used to generate the signature (plain-text; a= The algorithm used to generate the signature (plain-text;
REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256";
skipping to change at page 21, line 5 skipping to change at page 21, line 5
x-sig-c-tag-alg = hyphenated-word ; for later extension x-sig-c-tag-alg = hyphenated-word ; for later extension
d= The domain of the signing entity (plain-text; REQUIRED). This is d= The domain of the signing entity (plain-text; REQUIRED). This is
the domain that will be queried for the public key. This domain the domain that will be queried for the public key. This domain
MUST be the same as or a parent domain of the "i=" tag (the MUST be the same as or a parent domain of the "i=" tag (the
signing identity, as described below), or it MUST meet the signing identity, as described below), or it MUST meet the
requirements for parent domain signing described in Section 3.8. requirements for parent domain signing described in Section 3.8.
When presented with a signature that does not meet these When presented with a signature that does not meet these
requirement, verifiers MUST consider the signature invalid. requirement, verifiers MUST consider the signature invalid.
Internationalized domain names MUST be punycode-encoded Internationalized domain names MUST be encoded as described in
[RFC3492]. [RFC3490].
ABNF: ABNF:
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain) domain-name = sub-domain 1*("." sub-domain)
; from RFC 2821 Domain, but excluding address-literal ; from RFC 2821 Domain, but excluding address-literal
h= Signed header fields (plain-text, but see description; REQUIRED). h= Signed header fields (plain-text, but see description; REQUIRED).
A colon-separated list of header field names that identify the A colon-separated list of header field names that identify the
header fields presented to the signing algorithm. The field MUST header fields presented to the signing algorithm. The field MUST
skipping to change at page 22, line 13 skipping to change at page 22, line 13
actual header field with a null value. actual header field with a null value.
i= Identity of the user or agent (e.g., a mailing list manager) on i= Identity of the user or agent (e.g., a mailing list manager) on
behalf of which this message is signed (dkim-quoted-printable; behalf of which this message is signed (dkim-quoted-printable;
OPTIONAL, default is an empty local-part followed by an "@" OPTIONAL, default is an empty local-part followed by an "@"
followed by the domain from the "d=" tag). The syntax is a followed by the domain from the "d=" tag). The syntax is a
standard email address where the local-part MAY be omitted. The standard email address where the local-part MAY be omitted. The
domain part of the address MUST be the same as or a subdomain of domain part of the address MUST be the same as or a subdomain of
the value of the "d=" tag. the value of the "d=" tag.
Internationalized domain names MUST be punycode-encoded Internationalized domain names MUST be converted using the steps
[RFC3492]. listed in section 4 of [RFC3490] using the "ToASCII" function.
ABNF: ABNF:
sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" domain-name sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" domain-name
INFORMATIVE NOTE: The local-part of the "i=" tag is optional INFORMATIVE NOTE: The local-part of the "i=" tag is optional
because in some cases a signer may not be able to establish a because in some cases a signer may not be able to establish a
verified individual identity. In such cases, the signer may verified individual identity. In such cases, the signer may
wish to assert that although it is willing to go as far as wish to assert that although it is willing to go as far as
signing for the domain, it is unable or unwilling to commit signing for the domain, it is unable or unwilling to commit
skipping to change at page 34, line 17 skipping to change at page 34, line 17
Some messages, particularly those using 8-bit characters, are subject Some messages, particularly those using 8-bit characters, are subject
to modification during transit, notably conversion to 7-bit form. to modification during transit, notably conversion to 7-bit form.
Such conversions will break DKIM signatures. In order to minimize Such conversions will break DKIM signatures. In order to minimize
the chances of such breakage, signers SHOULD convert the message to a the chances of such breakage, signers SHOULD convert the message to a
suitable MIME content transfer encoding such as quoted-printable or suitable MIME content transfer encoding such as quoted-printable or
base64 as described in MIME Part One [RFC2045] before signing. Such base64 as described in MIME Part One [RFC2045] before signing. Such
conversion is outside the scope of DKIM; the actual message SHOULD be conversion is outside the scope of DKIM; the actual message SHOULD be
converted to 7-bit MIME by an MUA or MSA prior to presentation to the converted to 7-bit MIME by an MUA or MSA prior to presentation to the
DKIM algorithm. DKIM algorithm.
Should the message be submitted to the signer with any local encoding If the message is submitted to the signer with any local encoding
that will be modified before transmission, such conversion to that will be modified before transmission, that modification to
canonical form MUST be done before signing. In particular, some canonical [RFC2822] form MUST be done before signing. In particular,
systems use local line separator conventions (such as the Unix bare CR or LF characters (used by some systems as a local line
newline character) internally rather than the SMTP-standard CRLF separator convention) MUST be converted to the SMTP-standard CRLF
sequence. All such local conventions MUST be converted to canonical sequence before the message is signed. Any conversion of this sort
format before signing. SHOULD be applied to the message actually sent to the recipient(s),
not just to the version presented to the signing algorithm.
More generally, the signer MUST sign the message as it is expected to More generally, the signer MUST sign the message as it is expected to
be received by the verifier rather than in some local or internal be received by the verifier rather than in some local or internal
form. form.
5.4 Determine the header fields to Sign 5.4 Determine the header fields to Sign
The From header field MUST be signed (that is, included in the h= tag The From header field MUST be signed (that is, included in the h= tag
of the resulting DKIM-Signature header field). Signers SHOULD NOT of the resulting DKIM-Signature header field). Signers SHOULD NOT
sign an existing header field likely to be legitimately modified or sign an existing header field likely to be legitimately modified or
skipping to change at page 35, line 18 skipping to change at page 35, line 20
(that is, signers MAY include the header field name in the h= tag (that is, signers MAY include the header field name in the h= tag
even if that header field does not exist in the message). When even if that header field does not exist in the message). When
computing the signature, the non-existing header field MUST be computing the signature, the non-existing header field MUST be
treated as the null string (including the header field name, header treated as the null string (including the header field name, header
field value, all punctuation, and the trailing CRLF). field value, all punctuation, and the trailing CRLF).
INFORMATIVE RATIONALE: This allows signers to explicitly assert INFORMATIVE RATIONALE: This allows signers to explicitly assert
the absence of a header field; if that header field is added later the absence of a header field; if that header field is added later
the signature will fail. the signature will fail.
INFORMATIVE NOTE: A header field name need only be listed once
more than the actual number of that header field in a message at
the time of signing in order to prevent any further additions.
For example, if there is a single "Comments" header field at the
time of signing, listing "Comments" twice in the h= tag is
sufficient to prevent any number of Comments header fields from
being appended; it is not necessary (but is legal) to list
"Comments" three or more times in the h= tag.
Signers choosing to sign an existing header field that occurs more Signers choosing to sign an existing header field that occurs more
than once in the message (such as Received) MUST sign the physically than once in the message (such as Received) MUST sign the physically
last instance of that header field in the header block. Signers last instance of that header field in the header block. Signers
wishing to sign multiple instances of such a header field MUST wishing to sign multiple instances of such a header field MUST
include the header field name multiple times in the h= tag of the include the header field name multiple times in the h= tag of the
DKIM-Signature header field, and MUST sign such header fields in DKIM-Signature header field, and MUST sign such header fields in
order from the bottom of the header field block to the top. The order from the bottom of the header field block to the top. The
signer MAY include more instances of a header field name in h= than signer MAY include more instances of a header field name in h= than
there are actual corresponding header fields to indicate that there are actual corresponding header fields to indicate that
additional header fields of that name SHOULD NOT be added. additional header fields of that name SHOULD NOT be added.
skipping to change at page 39, line 32 skipping to change at page 39, line 46
in a DKIM-Signature header field, which are explicitly permitted. in a DKIM-Signature header field, which are explicitly permitted.
Verifiers MUST ignore DKIM-Signature header fields with a "v=" tag Verifiers MUST ignore DKIM-Signature header fields with a "v=" tag
that is inconsistent with this specification and return PERMFAIL that is inconsistent with this specification and return PERMFAIL
(incompatible version). (incompatible version).
INFORMATIVE IMPLEMENTATION NOTE: An implementation may, of INFORMATIVE IMPLEMENTATION NOTE: An implementation may, of
course, choose to also verify signatures generated by older course, choose to also verify signatures generated by older
versions of this specification. versions of this specification.
If the DKIM-Signature header field does not contain any of the tags If any tag listed as "required" in Section 3.5 is omitted from the
listed as required in Section 3.5 the verifier MUST ignore the DKIM- DKIM-Signature header field, the verifier MUST ignore the DKIM-
Signature header field and return PERMFAIL (signature missing Signature header field and return PERMFAIL (signature missing
required tag). required tag).
INFORMATIONAL NOTE: The tags listed as required in Section 3.5
are "v=", "a=", "b=", "bh=", "d=", "h=", and "s=". Should there
be a conflict between this note and Section 3.5, Section 3.5 is
normative.
If the "DKIM-Signature" header field does not contain the "i=" tag, If the "DKIM-Signature" header field does not contain the "i=" tag,
the verifier MUST behave as though the value of that tag were "@d", the verifier MUST behave as though the value of that tag were "@d",
where "d" is the value from the "d=" tag. where "d" is the value from the "d=" tag.
Verifiers MUST confirm that the domain specified in the "d=" tag is Verifiers MUST confirm that the domain specified in the "d=" tag is
the same as or a parent domain of the domain part of the "i=" tag. the same as or a parent domain of the domain part of the "i=" tag.
If not, the DKIM-Signature header field MUST be ignored and the If not, the DKIM-Signature header field MUST be ignored and the
verifier should return PERMFAIL (domain mismatch). verifier should return PERMFAIL (domain mismatch).
If the "h=" tag does not include the "From" header field the verifier If the "h=" tag does not include the "From" header field the verifier
skipping to change at page 44, line 41 skipping to change at page 45, line 13
in the system logs. However in terms of presentation to the end in the system logs. However in terms of presentation to the end
user, the result SHOULD be presented as a simple binary result: user, the result SHOULD be presented as a simple binary result:
either the email is verified or it is not. If the email cannot be either the email is verified or it is not. If the email cannot be
verified, then it SHOULD be rendered the same as all unverified email verified, then it SHOULD be rendered the same as all unverified email
regardless of whether it looks like it was signed or not. regardless of whether it looks like it was signed or not.
7. IANA Considerations 7. IANA Considerations
DKIM introduces some new namespaces that require IANA registry. DKIM introduces some new namespaces that require IANA registry.
[[Missing registries for signature t= (flags) tags, as well as key
record s= (service type) and t= (flags).]]
7.1 DKIM-Signature Tag Specifications 7.1 DKIM-Signature Tag Specifications
A DKIM-Signature provides for a list of tag specifications. IANA is A DKIM-Signature provides for a list of tag specifications. IANA is
requested to establish the DKIM Signature Tag Specification Registry, requested to establish the DKIM Signature Tag Specification Registry,
for tag specifications that can be used in DKIM-Signature fields and for tag specifications that can be used in DKIM-Signature fields and
that have been specified in any published RFC. that have been specified in any published RFC.
The initial entries in the registry comprise: The initial entries in the registry comprise:
+------+-----------------+ +------+-----------------+
skipping to change at page 47, line 40 skipping to change at page 48, line 14
The initial entries in the registry comprise: The initial entries in the registry comprise:
+--------+-----+ +--------+-----+
| TYPE | RFC | | TYPE | RFC |
+--------+-----+ +--------+-----+
| sha1 | ? | | sha1 | ? |
| sha256 | ? | | sha256 | ? |
+--------+-----+ +--------+-----+
7.7 DKIM Service Types Registry
The "s=" <key-s-tag> list (specified in Section 3.6.1) provides for a
list of service types to which this selector may apply.
IANA is requested to establish the DKIM Service Types Registry, for
service types that have been specified in any published RFC.
The initial entries in the registry comprise:
+-------+-----------------+
| TYPE | RFC |
+-------+-----------------+
| email | (this document) |
| * | (this document) |
+-------+-----------------+
7.8 DKIM Selector Flags Registry
The "t=" <key-t-tag> list (specified in Section 3.6.1) provides for a
list of flags to modify interpretation of the selector.
IANA is requested to establish the DKIM Selector Flags Registry, for
additional flags that have been specified in any published RFC.
The initial entries in the registry comprise:
+------+-----------------+
| TYPE | RFC |
+------+-----------------+
| y | (this document) |
| s | (this document) |
+------+-----------------+
8. Security Considerations 8. Security Considerations
It has been observed that any mechanism that is introduced which It has been observed that any mechanism that is introduced which
attempts to stem the flow of spam is subject to intensive attack. attempts to stem the flow of spam is subject to intensive attack.
DKIM needs to be carefully scrutinized to identify potential attack DKIM needs to be carefully scrutinized to identify potential attack
vectors and the vulnerability to each. See also [ID-DKIM-THREATS]. vectors and the vulnerability to each. See also [ID-DKIM-THREATS].
8.1 Misuse of Body Length Limits ("l=" Tag) 8.1 Misuse of Body Length Limits ("l=" Tag)
Body length limits (in the form of the "l=" tag) are subject to Body length limits (in the form of the "l=" tag) are subject to
skipping to change at page 52, line 28 skipping to change at page 53, line 36
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, February 2003.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
for Internationalized Domain Names in Application(IDNA)", "Internationalizing Domain Names in Applications (IDNA)",
March 2003. March 2003.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
[X.660] "ITU-T Recommendation X.660 Information Technology - ASN.1 [X.660] "ITU-T Recommendation X.660 Information Technology - ASN.1
encoding rules: Specification of Basic Encoding Rules encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished (BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)", 1997. Encoding Rules (DER)", 1997.
skipping to change at page 62, line 35 skipping to change at page 64, line 23
The DomainKeys specification was a primary source from which this The DomainKeys specification was a primary source from which this
specification has been derived. Further information about DomainKeys specification has been derived. Further information about DomainKeys
is at is at
<http://domainkeys.sourceforge.net/license/patentlicense1-1.html>. <http://domainkeys.sourceforge.net/license/patentlicense1-1.html>.
Appendix F. Edit History Appendix F. Edit History
[[This section to be removed before publication.]] [[This section to be removed before publication.]]
F.1 Changes since -ietf-03 version F.1 Changes since -ietf-04 version
The following changes were made between draft-ietf-dkim-base-04 and
draft-ietf-dkim-base-05:
o Clarified definition of "plain text" in section 3.2 (issue 1316).
o Added some clarification about multiple listings of non-existent
header field names in h= in section 5.4 (issue 1316).
o Finished filling out IANA registries in section 7 (issue 1320).
o Clarified handling of bare CR and LF in section 5.3 (issue 1326).
o Listed the required tags in section 6.1.1 as an informational note
(issue 1330).
o Changed IDNA reference from 3492 to 3490 (issue 1331).
o Changed the reference for WSP to 4234; changed the definition of
SWSP to exclude bare CR and LF (issue 1332).
F.2 Changes since -ietf-03 version
The following changes were made between draft-ietf-dkim-base-03 and The following changes were made between draft-ietf-dkim-base-03 and
draft-ietf-dkim-base-04: draft-ietf-dkim-base-04:
o Re-worded Abstract to avoid use of "prove" and "non-repudiation". o Re-worded Abstract to avoid use of "prove" and "non-repudiation".
o Use dot-atom-text instead of dot-atom to avoid inclusion of CFWS. o Use dot-atom-text instead of dot-atom to avoid inclusion of CFWS.
o Capitalize Selector throughout. o Capitalize Selector throughout.
skipping to change at page 63, line 44 skipping to change at page 66, line 7
data? data?
o Deal with "relaxed" body canonicalizations, especially in regard o Deal with "relaxed" body canonicalizations, especially in regard
to bare CRs and NLs. to bare CRs and NLs.
o How to handle "*" in g= dot-atom-text (which allows "*" as a o How to handle "*" in g= dot-atom-text (which allows "*" as a
literal character). literal character).
o The IANA Considerations need to be completed and cleaned up. o The IANA Considerations need to be completed and cleaned up.
F.2 Changes since -ietf-02 version F.3 Changes since -ietf-02 version
The following changes were made between draft-ietf-dkim-base-02 and The following changes were made between draft-ietf-dkim-base-02 and
draft-ietf-dkim-base-03: draft-ietf-dkim-base-03:
o Section 5.2: changed key expiration text to be informational; o Section 5.2: changed key expiration text to be informational;
drop "seven day" wording in favor of something vaguer. drop "seven day" wording in favor of something vaguer.
o Don't indicate that the "i=" tag value should be passed to the key o Don't indicate that the "i=" tag value should be passed to the key
lookup service; this can be added as an extension if required. lookup service; this can be added as an extension if required.
skipping to change at page 64, line 45 skipping to change at page 67, line 8
may contain the content. may contain the content.
o Use dkim-quoted-printable as the encoding used in z= rather than o Use dkim-quoted-printable as the encoding used in z= rather than
referring to RFC2045, since they are different. referring to RFC2045, since they are different.
o Rewrite description of g= tag in the key record. o Rewrite description of g= tag in the key record.
o Deleted use of Domain in ABNF, which permits address-literals; o Deleted use of Domain in ABNF, which permits address-literals;
define domain-name to act in stead. define domain-name to act in stead.
F.3 Changes since -ietf-01 version F.4 Changes since -ietf-01 version
The following changes were made between draft-ietf-dkim-base-01 and The following changes were made between draft-ietf-dkim-base-01 and
draft-ietf-dkim-base-02: draft-ietf-dkim-base-02:
o Change wording on "x=" tag in DKIM-Signature header field o Change wording on "x=" tag in DKIM-Signature header field
regarding verifier handling of expired signatures from MUST to MAY regarding verifier handling of expired signatures from MUST to MAY
(per 20 April Jabber session). Also, make it clear that received (per 20 April Jabber session). Also, make it clear that received
time is to be preferred over current time if reliably available. time is to be preferred over current time if reliably available.
o Several changes to limit wording that would intrude into verifier o Several changes to limit wording that would intrude into verifier
skipping to change at page 65, line 28 skipping to change at page 67, line 39
o Change "q=dns" query access method to "q=dnstxt" to emphasize the o Change "q=dns" query access method to "q=dnstxt" to emphasize the
use of the TXT record. The expectation is that a later extension use of the TXT record. The expectation is that a later extension
will define "q=dnsdkk" to indicate use of a DKK record. (Per 18 will define "q=dnsdkk" to indicate use of a DKK record. (Per 18
May Jabber session.) May Jabber session.)
o Several typos fixed, including removing a paragraph that implied o Several typos fixed, including removing a paragraph that implied
that the DKIM-Signature header field should be hashed with the that the DKIM-Signature header field should be hashed with the
body (it should not). body (it should not).
F.4 Changes since -ietf-00 version F.5 Changes since -ietf-00 version
The following changes were made between draft-ietf-dkim-base-00 and The following changes were made between draft-ietf-dkim-base-00 and
draft-ietf-dkim-base-01: draft-ietf-dkim-base-01:
o Added section 8.9 (Information Leakage). o Added section 8.9 (Information Leakage).
o Replace section 4 (Multiple Signatures) with much less vague text. o Replace section 4 (Multiple Signatures) with much less vague text.
o Fixed ABNF for base64string. o Fixed ABNF for base64string.
skipping to change at page 66, line 7 skipping to change at page 68, line 18
o Changed signing algorithm to use separate hash of the body of the o Changed signing algorithm to use separate hash of the body of the
message; this is represented as the "bh=" tag in the DKIM- message; this is represented as the "bh=" tag in the DKIM-
Signature header field. Signature header field.
o Changed "z=" tag so that it need not have the same header field o Changed "z=" tag so that it need not have the same header field
names as the "h=" tag. names as the "h=" tag.
o Significant wordsmithing. o Significant wordsmithing.
F.5 Changes since -allman-01 version F.6 Changes since -allman-01 version
The following changes were made between draft-allman-dkim-base-01 and The following changes were made between draft-allman-dkim-base-01 and
draft-ietf-dkim-base-00: draft-ietf-dkim-base-00:
o Remove references to Sender Signing Policy document. Such o Remove references to Sender Signing Policy document. Such
consideration is implicitly included in Section 6.3. consideration is implicitly included in Section 6.3.
o Added ABNF for all tags. o Added ABNF for all tags.
o Updated references (still includes some references to expired o Updated references (still includes some references to expired
drafts, notably ID-AUTH-RES. drafts, notably ID-AUTH-RES.
o Significant wordsmithing. o Significant wordsmithing.
F.6 Changes since -allman-00 version F.7 Changes since -allman-00 version
The following changes were made between draft-allman-dkim-base-00 and The following changes were made between draft-allman-dkim-base-00 and
draft-allman-dkim-base-01: draft-allman-dkim-base-01:
o Changed "c=" tag to separate out header from body o Changed "c=" tag to separate out header from body
canonicalization. canonicalization.
o Eliminated "nowsp" canonicalization in favor of "relaxed", which o Eliminated "nowsp" canonicalization in favor of "relaxed", which
is somewhat less relaxed (but more secure) than "nowsp". is somewhat less relaxed (but more secure) than "nowsp".
 End of changes. 40 change blocks. 
92 lines changed or deleted 166 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/