draft-ietf-dkim-base-06.txt   draft-ietf-dkim-base-07.txt 
DKIM E. Allman DKIM E. Allman
Internet-Draft Sendmail, Inc. Internet-Draft Sendmail, Inc.
Expires: April 23, 2007 J. Callas Expires: June 7, 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.
October 20, 2006 December 4, 2006
DomainKeys Identified Mail (DKIM) Signatures DomainKeys Identified Mail (DKIM) Signatures
draft-ietf-dkim-base-06 draft-ietf-dkim-base-07
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 April 23, 2007. This Internet-Draft will expire on June 7, 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 19 skipping to change at page 3, line 19
1.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 1.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Simple Key Management . . . . . . . . . . . . . . . . . . 6 1.3 Simple Key Management . . . . . . . . . . . . . . . . . . 6
2. Terminology and Definitions . . . . . . . . . . . . . . . . 6 2. Terminology and Definitions . . . . . . . . . . . . . . . . 6
2.1 Signers . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1 Signers . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 White Space . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 White Space . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 7 2.4 Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 7
2.5 Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 8 2.5 Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 8
2.6 DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 8 2.6 DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 8
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . 9 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . 9
3.1 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 11 3.2 Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 11
3.3 Signing and Verification Algorithms . . . . . . . . . . . 12 3.3 Signing and Verification Algorithms . . . . . . . . . . . 12
3.4 Canonicalization . . . . . . . . . . . . . . . . . . . . . 14 3.4 Canonicalization . . . . . . . . . . . . . . . . . . . . . 14
3.5 The DKIM-Signature header field . . . . . . . . . . . . . 18 3.5 The DKIM-Signature header field . . . . . . . . . . . . . 18
3.6 Key Management and Representation . . . . . . . . . . . . 25 3.6 Key Management and Representation . . . . . . . . . . . . 25
3.7 Computing the Message Hashes . . . . . . . . . . . . . . . 29 3.7 Computing the Message Hashes . . . . . . . . . . . . . . . 30
3.8 Signing by Parent Domains . . . . . . . . . . . . . . . . 31 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 . . . . . . . . . . . . . . . . . . . . . . . 33
5.1 Determine if the Email Should be Signed and by Whom . . . 32 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 . . 33 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 . . . . . . . . . . . . . 42 6.2 Communicate Verification Results . . . . . . . . . . . . . 43
6.3 Interpret Results/Apply Local Policy . . . . . . . . . . . 43 6.3 Interpret Results/Apply Local Policy . . . . . . . . . . . 44
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 . . . . . . . . . . . 46
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 . . . . . . . 47
7.5 DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 47 7.5 DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 48
7.6 DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 47 7.6 DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 48
7.7 DKIM Service Types Registry . . . . . . . . . . . . . . . 47 7.7 DKIM Service Types Registry . . . . . . . . . . . . . . . 48
7.8 DKIM Selector Flags Registry . . . . . . . . . . . . . . . 48 7.8 DKIM Selector Flags Registry . . . . . . . . . . . . . . . 49
8. Security Considerations . . . . . . . . . . . . . . . . . . 48 7.9 DKIM-Signature Header Field . . . . . . . . . . . . . . . 49
8.1 Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 48 8. Security Considerations . . . . . . . . . . . . . . . . . . 49
8.2 Misappropriated Private Key . . . . . . . . . . . . . . . 49 8.1 Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 49
8.3 Key Server Denial-of-Service Attacks . . . . . . . . . . . 50 8.2 Misappropriated Private Key . . . . . . . . . . . . . . . 50
8.4 Attacks Against DNS . . . . . . . . . . . . . . . . . . . 50 8.3 Key Server Denial-of-Service Attacks . . . . . . . . . . . 51
8.5 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 51 8.4 Attacks Against DNS . . . . . . . . . . . . . . . . . . . 51
8.6 Limits on Revoking Keys . . . . . . . . . . . . . . . . . 51 8.5 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 52
8.7 Intentionally malformed Key Records . . . . . . . . . . . 52 8.6 Limits on Revoking Keys . . . . . . . . . . . . . . . . . 53
8.8 Intentionally Malformed DKIM-Signature header fields . . . 52 8.7 Intentionally malformed Key Records . . . . . . . . . . . 53
8.9 Information Leakage . . . . . . . . . . . . . . . . . . . 52 8.8 Intentionally Malformed DKIM-Signature header fields . . . 53
8.10 Remote Timing Attacks . . . . . . . . . . . . . . . . . 52 8.9 Information Leakage . . . . . . . . . . . . . . . . . . . 53
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 8.10 Remote Timing Attacks . . . . . . . . . . . . . . . . . 53
9.1 Normative References . . . . . . . . . . . . . . . . . . . 52 8.11 Reordered Header Fields . . . . . . . . . . . . . . . . 54
9.2 Informative References . . . . . . . . . . . . . . . . . . 53 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 54 9.1 Normative References . . . . . . . . . . . . . . . . . . . 54
A. Example of Use (INFORMATIVE) . . . . . . . . . . . . . . . . 55 9.2 Informative References . . . . . . . . . . . . . . . . . . 55
A.1 The user composes an email . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55
A.2 The email is signed . . . . . . . . . . . . . . . . . . . 56 A. Example of Use (INFORMATIVE) . . . . . . . . . . . . . . . . 57
A.3 The email signature is verified . . . . . . . . . . . . . 56 A.1 The user composes an email . . . . . . . . . . . . . . . . 57
B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . . . . . 57 A.2 The email is signed . . . . . . . . . . . . . . . . . . . 57
B.1 Alternate Submission Scenarios . . . . . . . . . . . . . . 58 A.3 The email signature is verified . . . . . . . . . . . . . 58
B.2 Alternate Delivery Scenarios . . . . . . . . . . . . . . . 60 B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . . . . . 59
C. Creating a public key (INFORMATIVE) . . . . . . . . . . . . 62 B.1 Alternate Submission Scenarios . . . . . . . . . . . . . . 59
D. MUA Considerations . . . . . . . . . . . . . . . . . . . . . 64 B.2 Alternate Delivery Scenarios . . . . . . . . . . . . . . . 62
E. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65 C. Creating a public key (INFORMATIVE) . . . . . . . . . . . . 64
F. Edit History . . . . . . . . . . . . . . . . . . . . . . . . 65 D. MUA Considerations . . . . . . . . . . . . . . . . . . . . . 65
F.1 Changes since -ietf-05 version . . . . . . . . . . . . . . 65 E. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 66
F.2 Changes since -ietf-04 version . . . . . . . . . . . . . . 66 F. Edit History . . . . . . . . . . . . . . . . . . . . . . . . 66
F.3 Changes since -ietf-03 version . . . . . . . . . . . . . . 66 F.1 Changes since -ietf-06 version . . . . . . . . . . . . . . 67
F.4 Changes since -ietf-02 version . . . . . . . . . . . . . . 67 F.2 Changes since -ietf-05 version . . . . . . . . . . . . . . 67
F.5 Changes since -ietf-01 version . . . . . . . . . . . . . . 68 F.3 Changes since -ietf-04 version . . . . . . . . . . . . . . 68
F.6 Changes since -ietf-00 version . . . . . . . . . . . . . . 69 F.4 Changes since -ietf-03 version . . . . . . . . . . . . . . 68
F.7 Changes since -allman-01 version . . . . . . . . . . . . . 69 F.5 Changes since -ietf-02 version . . . . . . . . . . . . . . 69
F.8 Changes since -allman-00 version . . . . . . . . . . . . . 70 F.6 Changes since -ietf-01 version . . . . . . . . . . . . . . 70
Intellectual Property and Copyright Statements . . . . . . . 71 F.7 Changes since -ietf-00 version . . . . . . . . . . . . . . 71
F.8 Changes since -allman-01 version . . . . . . . . . . . . . 71
F.9 Changes since -allman-00 version . . . . . . . . . . . . . 72
Intellectual Property and Copyright Statements . . . . . . . 73
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 5, line 32 skipping to change at page 5, line 32
neither human recipients nor existing MUA (Mail User Agent) neither human recipients nor existing MUA (Mail User Agent)
software are confused by signature-related content appearing in software are confused by signature-related content appearing in
the message body; the message body;
o there is no dependency on public and private key pairs being o there is no dependency on public and private key pairs being
issued by well-known, trusted certificate authorities; issued by well-known, trusted certificate authorities;
o there is no dependency on the deployment of any new Internet o there is no dependency on the deployment of any new Internet
protocols or services for public key distribution or revocation; protocols or services for public key distribution or revocation;
o signature verification failure does not result in rejection of the o signature verification failure does not force rejection of the
message; message;
o no attempt is made to include encryption as part of the mechanism; o no attempt is made to include encryption as part of the mechanism;
o archival is not a design goal. o message archiving is not a design goal.
DKIM: DKIM:
o is compatible with the existing email infrastructure and o is compatible with the existing email infrastructure and
transparent to the fullest extent possible; transparent to the fullest extent possible;
o requires minimal new infrastructure; o requires minimal new infrastructure;
o can be implemented independently of clients in order to reduce o can be implemented independently of clients in order to reduce
deployment time; deployment time;
skipping to change at page 8, line 12 skipping to change at page 8, line 12
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 / "+" / "/" / LWSP) base64string = 1*(ALPHA / DIGIT / "+" / "/" / LWSP)
[ "=" *LWSP [ "=" *LWSP ] ] [ "=" *LWSP [ "=" *LWSP ] ]
2.5 Imported ABNF Tokens 2.5 Imported ABNF Tokens
The following tokens are imported from other RFCs as noted. Those The following tokens are imported from other RFCs as noted. Those
RFCs should be considered definitive. However, all tokens having RFCs should be considered definitive.
names beginning with "obs-" should be excluded from this import, as
they have been obsoleted and are expected to go away in future
editions of those RFCs.
The following tokens are imported from [RFC2821]: The following tokens are imported from [RFC2821]:
o "Local-part" (implementation warning: this permits quoted o "Local-part" (implementation warning: this permits quoted
strings) strings)
o "sub-domain" o "sub-domain"
The following definitions are imported from [RFC2822]: The following tokens are imported from [RFC2822]:
o "field-name" (name of a header field) o "field-name" (name of a header field)
o "dot-atom-text" (in the local-part of an email address) o "dot-atom-text" (in the local-part of an email address)
The following tokens are imported from [RFC2045]: The following tokens are imported from [RFC2045]:
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)
skipping to change at page 9, line 25 skipping to change at page 9, line 22
dkim-safe-char = %x21-3A / %x3C / %x3E-7E dkim-safe-char = %x21-3A / %x3C / %x3E-7E
; '!' - ':', '<', '>' - '~' ; '!' - ':', '<', '>' - '~'
; Characters not listed as "mail-safe" in ; Characters not listed as "mail-safe" in
; RFC 2049 are also not recommended. ; RFC 2049 are also not recommended.
INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted- INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted-
Printable as defined in RFC 2045 in several important ways: Printable as defined in RFC 2045 in several important ways:
1. White space in the input text, including CR and LF, must be 1. White space in the input text, including CR and LF, must be
encoded. RFC 2045 does not require such encoding, and does encoded. RFC 2045 does not require such encoding, and does
not permit encoded of CR or LF characters that are part of a not permit encoding of CR or LF characters that are part of a
CRLF line break. CRLF line break.
2. White space in the encoded text is ignored. This is to allow 2. White space in the encoded text is ignored. This is to allow
DKIM-Quoted-Printable to be wrapped as needed in headers. In tags encoded using DKIM-Quoted-Printable to be wrapped as
particular, RFC 2045 requires that line breaks in the input be needed. In particular, RFC 2045 requires that line breaks in
represented as physical line breaks; that is not the case the input be represented as physical line breaks; that is not
here. the case here.
3. The "soft line break" syntax ("=" as the last non-white-space 3. The "soft line break" syntax ("=" as the last non-white-space
character on the line) does not apply. character on the line) does not apply.
4. DKIM-Quoted-Printable does not require that encoded lines be 4. DKIM-Quoted-Printable does not require that encoded lines be
no more than 76 characters long (although there may be other no more than 76 characters long (although there may be other
requirements depending on the context in which the encoded requirements depending on the context in which the encoded
text is being used). text is being used).
3. Protocol Elements 3. Protocol Elements
skipping to change at page 11, line 40 skipping to change at page 11, line 37
a new key, signers SHOULD associate it with a new Selector. a new key, signers SHOULD associate it with a new Selector.
3.2 Tag=Value Lists 3.2 Tag=Value Lists
DKIM uses a simple "tag=value" syntax in several contexts, including DKIM uses a simple "tag=value" syntax in several contexts, including
in messages and domain signature records. in messages and domain signature records.
Values are a series of strings containing either plain text, "base64" Values are a series of strings containing either plain text, "base64"
text (as defined in [RFC2045], section 6.8), "qp-section" (ibid, text (as defined in [RFC2045], section 6.8), "qp-section" (ibid,
section 6.7), or "dkim-quoted-printable" (as defined in Section 2.6). section 6.7), or "dkim-quoted-printable" (as defined in Section 2.6).
The name of the tag will determine the encoding of each value; The name of the tag will determine the encoding of each value.
however, no encoding may include the semicolon (";") character, since Unencoded semicolon (";") characters MUST NOT occur in the tag value,
that separates tag-specs. since that separates tag-specs.
INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text"
defined below (as "tag-value") only includes 7-bit characters, an defined below (as "tag-value") only includes 7-bit characters, an
implementation that wished to anticipate future standards would be implementation that wished to anticipate future standards would be
advised to not preclude the use of UTF8-encoded text in tag=value advised to not preclude the use of UTF8-encoded text in tag=value
lists. lists.
Formally, the syntax rules are: Formally, the syntax rules are:
tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ]
tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
skipping to change at page 12, line 24 skipping to change at page 12, line 24
ALNUMPUNC = ALPHA / DIGIT / "_" ALNUMPUNC = ALPHA / DIGIT / "_"
Note that WSP is allowed anywhere around tags; in particular, any WSP Note that WSP is allowed anywhere around tags; in particular, any WSP
after the "=" and any WSP before the terminating ";" is not part of after the "=" and any WSP before the terminating ";" is not part of
the value; however, WSP inside the value is significant. the value; however, WSP inside the value is significant.
Tags MUST be interpreted in a case-sensitive manner. Values MUST be Tags MUST be interpreted in a case-sensitive manner. Values MUST be
processed as case sensitive unless the specific tag description of processed as case sensitive unless the specific tag description of
semantics specifies case insensitivity. semantics specifies case insensitivity.
Tags with duplicate names MUST NOT be specified within a single tag- Tags with duplicate names MUST NOT occur within a single tag-list; if
list. a tag name does occur more than once, the entire tag-list is invalid.
Whitespace within a value MUST be retained unless explicitly excluded Whitespace within a value MUST be retained unless explicitly excluded
by the specific tag description. by the specific tag description.
Tag=value pairs that represent the default value MAY be included to Tag=value pairs that represent the default value MAY be included to
aid legibility. aid legibility.
Unrecognized tags MUST be ignored. Unrecognized tags MUST be ignored.
Tags that have an empty value are not the same as omitted tags. An Tags that have an empty value are not the same as omitted tags. An
skipping to change at page 12, line 49 skipping to change at page 12, line 49
for that tag. for that tag.
3.3 Signing and Verification Algorithms 3.3 Signing and Verification Algorithms
DKIM supports multiple digital signature algorithms. Two algorithms DKIM supports multiple digital signature algorithms. Two algorithms
are defined by this specification at this time: rsa-sha1, and rsa- are defined by this specification at this time: rsa-sha1, and rsa-
sha256. The rsa-sha256 algorithm is the default if no algorithm is sha256. The rsa-sha256 algorithm is the default if no algorithm is
specified. Verifiers MUST implement both rsa-sha1 and rsa-sha256. specified. Verifiers MUST implement both rsa-sha1 and rsa-sha256.
Signers MUST implement and SHOULD sign using rsa-sha256. Signers MUST implement and SHOULD sign using rsa-sha256.
INFORMATIVE NOTE: Although sha256 is strongly encouraged, some
senders of low-security messages (such as routine newsletters) may
prefer to use sha1 because of reduced CPU requirements to compute
a sha1 hash. In general, sha256 should always be used whenever
possible.
3.3.1 The rsa-sha1 Signing Algorithm 3.3.1 The rsa-sha1 Signing Algorithm
The rsa-sha1 Signing Algorithm computes a message hash as described The rsa-sha1 Signing Algorithm computes a message hash as described
in Section 3.7 below using SHA-1 [SHA] as the hash-alg. That hash is in Section 3.7 below using SHA-1 [SHA] as the hash-alg. That hash is
then signed by the signer using the RSA algorithm (defined in PKCS#1 then signed by the signer using the RSA algorithm (defined in PKCS#1
version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. version 1.5 [RFC3447]) as the crypt-alg and the signer's private key.
The hash MUST NOT be truncated or converted into any form other than The hash MUST NOT be truncated or converted into any form other than
the native binary form before being signed. the native binary form before being signed.
INFORMATIVE IMPLEMENTATION WARNING: Low-valued exponents should INFORMATIVE IMPLEMENTATION WARNING: Low-valued exponents should
be avoided, as they are believed to be subject to attack. be avoided, as they are believed to be subject to attack.
3.3.2 The rsa-sha256 Signing Algorithm 3.3.2 The rsa-sha256 Signing Algorithm
The rsa-sha256 Signing Algorithm computes a message hash as described The rsa-sha256 Signing Algorithm computes a message hash as described
in Section 3.7 below using SHA-256 [SHA] as the hash-alg. That hash in Section 3.7 below using SHA-256 [SHA] as the hash-alg. That hash
is then signed by the signer using the RSA algorithm (actually PKCS#1 is then signed by the signer using the RSA algorithm (defined in
version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the signer's
The hash MUST NOT be truncated or converted into any form other than private key. The hash MUST NOT be truncated or converted into any
the native binary form before being signed. form other than the native binary form before being signed.
3.3.3 Key sizes 3.3.3 Key sizes
Selecting appropriate key sizes is a trade-off between cost, Selecting appropriate key sizes is a trade-off between cost,
performance and risk. Since short RSA keys more easily succumb to performance and risk. Since short RSA keys more easily succumb to
off-line attacks, signers MUST use RSA keys of at least 1024 bits for off-line attacks, signers MUST use RSA keys of at least 1024 bits for
long-lived keys. Verifiers MUST be able to validate signatures with long-lived keys. Verifiers MUST be able to validate signatures with
keys ranging from 512 bits to 2048 bits, and they MAY be able to keys ranging from 512 bits to 2048 bits, and they MAY be able to
validate signatures with larger keys. Verifier policies may use the validate signatures with larger keys. Verifier policies may use the
length of the signing key as one metric for determining whether a length of the signing key as one metric for determining whether a
skipping to change at page 13, line 44 skipping to change at page 14, line 4
o The practical constraint that large keys may not fit within a 512 o The practical constraint that large keys may not fit within a 512
byte DNS UDP response packet byte DNS UDP response packet
o The security constraint that keys smaller than 1024 bits are o The security constraint that keys smaller than 1024 bits are
subject to off-line attacks subject to off-line attacks
o Larger keys impose higher CPU costs to verify and sign email o Larger keys impose higher CPU costs to verify and sign email
o Keys can be replaced on a regular basis, thus their lifetime can o Keys can be replaced on a regular basis, thus their lifetime can
be relatively short be relatively short
o The security goals of this specification are modest compared to o The security goals of this specification are modest compared to
typical goals of other systems that employ digital signatures typical goals of other systems that employ digital signatures
See [RFC3766] for further discussion of selecting key sizes. See [RFC3766] for further discussion on selecting key sizes.
3.3.4 Other algorithms 3.3.4 Other algorithms
Other algorithms MAY be defined in the future. Verifiers MUST ignore Other algorithms MAY be defined in the future. Verifiers MUST ignore
any signatures using algorithms that they do not implement. any signatures using algorithms that they do not implement.
3.4 Canonicalization 3.4 Canonicalization
Empirical evidence demonstrates that some mail servers and relay Empirical evidence demonstrates that some mail servers and relay
systems modify email in transit, potentially invalidating a systems modify email in transit, potentially invalidating a
skipping to change at page 15, line 5 skipping to change at page 15, line 8
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
body are described below. body are described below.
NOTE: This section assumes that the message is already in "network NOTE: This section assumes that the message is already in "network
normal" format (e.g., text is ASCII encoded, lines are separated with normal" format (e.g., text is ASCII encoded, lines are separated with
CRLF characters, etc.). See also Section 5.3 for information about CRLF characters, etc.). See also Section 5.3 for information about
normalizing the message. normalizing the message.
3.4.1 The "simple" Header Field Canonicalization Algorithm 3.4.1 The "simple" Header Canonicalization Algorithm
The "simple" header canonicalization algorithm does not change header The "simple" header canonicalization algorithm does not change header
fields in any way. Header fields MUST be presented to the signing or fields in any way. Header fields MUST be presented to the signing or
verification algorithm exactly as they are in the message being verification algorithm exactly as they are in the message being
signed or verified. In particular, header field names MUST NOT be signed or verified. In particular, header field names MUST NOT be
case folded and white space MUST NOT be changed. case folded and white space MUST NOT be changed.
3.4.2 The "relaxed" Header Field Canonicalization Algorithm 3.4.2 The "relaxed" Header Canonicalization Algorithm
The "relaxed" header canonicalization algorithm MUST apply the The "relaxed" header canonicalization algorithm MUST apply the
following steps in order: following steps in order:
o Convert all header field names (not the header field values) to o Convert all header field names (not the header field values) to
lower case. For example, convert "SUBJect: AbC" to "subject: lower case. For example, convert "SUBJect: AbC" to "subject:
AbC". AbC".
o Unfold all header field continuation lines as described in o Unfold all header field continuation lines as described in
[RFC2822]; in particular, lines with terminators embedded in [RFC2822]; in particular, lines with terminators embedded in
skipping to change at page 18, line 26 skipping to change at page 18, line 30
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
hence SHOULD NOT be reordered and SHOULD be prepended to the message. hence SHOULD NOT be reordered and SHOULD be prepended to the message.
The "DKIM-Signature:" header field being created or verified is The "DKIM-Signature:" header field being created or verified is
always included in the signature calculation, after the body of the always included in the signature calculation, after the rest of the
message; however, when calculating or verifying the signature, the header fields being signed; however, when calculating or verifying
value of the b= tag (signature value) of that DKIM-Signature header the signature, the value of the b= tag (signature value) of that
field MUST be treated as though it were an empty string. Unknown DKIM-Signature header field MUST be treated as though it were an
tags in the "DKIM-Signature:" header field MUST be included in the empty string. Unknown tags in the "DKIM-Signature:" header field
signature calculation but MUST be otherwise ignored by verifiers. MUST be included in the signature calculation but MUST be otherwise
Other "DKIM-Signature:" header fields that are included in the ignored by verifiers. Other "DKIM-Signature:" header fields that are
signature should be treated as normal header fields; in particular, included in the signature should be treated as normal header fields;
the b= tag is not treated specially. in particular, the b= tag is not treated specially.
The encodings for each field type are listed below. Tags described The encodings for each field type are listed below. Tags described
as qp-section are encoded as described in section 6.7 of MIME Part as qp-section are encoded as described in section 6.7 of MIME Part
One [RFC2045], with the additional conversion of semicolon characters One [RFC2045], with the additional conversion of semicolon characters
to "=3B"; intuitively, this is one line of quoted-printable encoded to "=3B"; intuitively, this is one line of quoted-printable encoded
text. The dkim-quoted-printable syntax is defined in Section 2.6. text. The dkim-quoted-printable syntax is defined in 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.
skipping to change at page 23, line 37 skipping to change at page 23, line 45
Currently the only valid value is "dns/txt" which defines the DNS Currently the only valid value is "dns/txt" which defines the DNS
TXT record lookup algorithm described elsewhere in this document. TXT record lookup algorithm described elsewhere in this document.
The only option defined for the "dns" query type is "txt", which The only option defined for the "dns" query type is "txt", which
MUST be included. Verifiers and signers MUST support "dns/txt". MUST be included. Verifiers and signers MUST support "dns/txt".
ABNF: ABNF:
sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method
*([FWS] ":" [FWS] sig-q-tag-method) *([FWS] ":" [FWS] sig-q-tag-method)
sig-q-tag-method = "dns/txt" / x-sig-q-tag-type ["/" x-sig-q-tag-args] sig-q-tag-method = "dns/txt" / x-sig-q-tag-type
["/" x-sig-q-tag-args]
x-sig-q-tag-type = hyphenated-word ; for future extension x-sig-q-tag-type = hyphenated-word ; for future extension
x-sig-q-tag-args = qp-hdr-value x-sig-q-tag-args = qp-hdr-value
s= The Selector subdividing the namespace for the "d=" (domain) tag s= The Selector subdividing the namespace for the "d=" (domain) tag
(plain-text; REQUIRED). (plain-text; REQUIRED).
ABNF: ABNF:
sig-s-tag = %x73 [FWS] "=" [FWS] selector sig-s-tag = %x73 [FWS] "=" [FWS] selector
t= Signature Timestamp (plain-text unsigned decimal integer; t= Signature Timestamp (plain-text unsigned decimal integer;
RECOMMENDED, default is an unknown creation time). The time that RECOMMENDED, default is an unknown creation time). The time that
this signature was created. The format is the number of seconds this signature was created. The format is the number of seconds
since 00:00:00 on January 1, 1970 in the UTC time zone. The since 00:00:00 on January 1, 1970 in the UTC time zone. The
value is expressed as an unsigned integer in decimal ASCII. This value is expressed as an unsigned integer in decimal ASCII. This
value is not constrained to fit into a 31- or 32-bit integer. value is not constrained to fit into a 31- or 32-bit integer.
Implementations SHOULD be prepared to handle values up to at Implementations SHOULD be prepared to handle values up to at
least 10^12 (until approximately AD 200,000; this fits into 40 least 10^12 (until approximately AD 200,000; this fits into 40
bits). To avoid denial of service attacks, implementations MAY bits). To avoid denial of service attacks, implementations MAY
consider any value longer than 12 digits to be infinite. Leap consider any value longer than 12 digits to be infinite. Leap
skipping to change at page 25, line 28 skipping to change at page 25, line 38
ABNF: ABNF:
sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy
*( [FWS] "|" sig-z-tag-copy ) *( [FWS] "|" sig-z-tag-copy )
sig-z-tag-copy = hdr-name ":" qp-hdr-value sig-z-tag-copy = hdr-name ":" qp-hdr-value
qp-hdr-value = dkim-quoted-printable ; with "|" encoded qp-hdr-value = dkim-quoted-printable ; with "|" encoded
INFORMATIVE EXAMPLE of a signature header field spread across INFORMATIVE EXAMPLE of a signature header field spread across
multiple continuation lines: multiple continuation lines:
DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane; DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane;
c=simple; q=dns/txt; i=@eng.example.net; t=1117574938; x=1118006938; c=simple; q=dns/txt; i=@eng.example.net;
t=1117574938; x=1118006938;
h=from:to:subject:date; h=from:to:subject:date;
z=From:foo@eng.example.net|To:joe@example.com| z=From:foo@eng.example.net|To:joe@example.com|
Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700; Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR VoG4ZHRNiYzR
3.6 Key Management and Representation 3.6 Key Management and Representation
Signature applications require some level of assurance that the Signature applications require some level of assurance that the
skipping to change at page 28, line 4 skipping to change at page 28, line 17
x-key-k-tag-type = hyphenated-word ; for future extension x-key-k-tag-type = hyphenated-word ; for future extension
n= Notes that might be of interest to a human (qp-section; OPTIONAL, n= Notes that might be of interest to a human (qp-section; OPTIONAL,
default is empty). No interpretation is made by any program. default is empty). No interpretation is made by any program.
This tag should be used sparingly in any key server mechanism This tag should be used sparingly in any key server mechanism
that has space limitations (notably DNS). that has space limitations (notably DNS).
ABNF: ABNF:
key-n-tag = %x6e [FWS] "=" [FWS] qp-section key-n-tag = %x6e [FWS] "=" [FWS] qp-section
p= Public-key data (base64; REQUIRED). An empty value means that p= Public-key data (base64; REQUIRED). An empty value means that
this public key has been revoked. The syntax and semantics of this public key has been revoked. The syntax and semantics of
this tag value before being encoded in base64 is defined by the this tag value before being encoded in base64 is defined by the
k= tag. k= tag.
INFORMATIVE RATIONALE: If a private key has been compromised
or otherwise disabled (e.g., an outsourcing contract has been
terminated), a signer might want to explicitly state that it
knows about the selector, but all messages using that
selector should fail verification. Verifiers should ignore
any DKIM-Signature header fields with a selector referencing
a revoked key.
ABNF: ABNF:
key-p-tag = %x70 [FWS] "=" [ [FWS] base64string ] key-p-tag = %x70 [FWS] "=" [ [FWS] base64string ]
s= Service Type (plain-text; OPTIONAL; default is "*"). A colon- s= Service Type (plain-text; OPTIONAL; default is "*"). A colon-
separated list of service types to which this record applies. separated list of service types to which this record applies.
Verifiers for a given service type MUST ignore this record if the Verifiers for a given service type MUST ignore this record if the
appropriate type is not listed. Currently defined service types appropriate type is not listed. Currently defined service types
are: are:
skipping to change at page 29, line 26 skipping to change at page 29, line 47
A binding using DNS TXT records as a key service is hereby defined. A binding using DNS TXT records as a key service is hereby defined.
All implementations MUST support this binding. All implementations MUST support this binding.
3.6.2.1 Name Space 3.6.2.1 Name Space
All DKIM keys are stored in a subdomain named "_domainkey". Given a All DKIM keys are stored in a subdomain named "_domainkey". Given a
DKIM-Signature field with a "d=" tag of "example.com" and an "s=" tag DKIM-Signature field with a "d=" tag of "example.com" and an "s=" tag
of "foo.bar", the DNS query will be for of "foo.bar", the DNS query will be for
"foo.bar._domainkey.example.com". "foo.bar._domainkey.example.com".
Wildcard DNS records (e.g., *.bar._domainkey.example.com) MUST NOT be INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records (e.g.,
used. Note also that wildcards within domains (e.g., *.bar._domainkey.example.com) do not make sense in this context
s._domainkey.*.example.com) are not supported by the DNS. and should not be used. Note also that wildcards within domains
(e.g., s._domainkey.*.example.com) are not supported by the DNS.
3.6.2.2 Resource Record Types for Key Storage 3.6.2.2 Resource Record Types for Key Storage
The DNS Resource Record type used is specified by an option to the The DNS Resource Record type used is specified by an option to the
query-type ("q=") tag. The only option defined in this base query-type ("q=") tag. The only option defined in this base
specification is "txt", indicating the use of a TXT Resource Record specification is "txt", indicating the use of a TXT Resource Record
(RR). A later extension of this standard may define another RR type. (RR). A later extension of this standard may define another RR type.
Strings in a TXT RR MUST be concatenated together before use with no Strings in a TXT RR MUST be concatenated together before use with no
intervening white space. TXT RRs MUST be unique for a particular intervening white space. TXT RRs MUST be unique for a particular
skipping to change at page 30, line 45 skipping to change at page 31, line 24
tag, and without a trailing CRLF. tag, and without a trailing CRLF.
All tags and their values in the DKIM-Signature header field are All tags and their values in the DKIM-Signature header field are
included in the cryptographic hash with the sole exception of the included in the cryptographic hash with the sole exception of the
value portion of the "b=" (signature) tag, which MUST be treated as value portion of the "b=" (signature) tag, which MUST be treated as
the null string. All tags MUST be included even if they might not be the null string. All tags MUST be included even if they might not be
understood by the verifier. The header field MUST be presented to understood by the verifier. The header field MUST be presented to
the hash algorithm after the body of the message rather than with the the hash algorithm after the body of the message rather than with the
rest of the header fields and MUST be canonicalized as specified in rest of the header fields and MUST be canonicalized as specified in
the "c=" (canonicalization) tag. The DKIM-Signature header field the "c=" (canonicalization) tag. The DKIM-Signature header field
MUST NOT be included in its own h= tag. MUST NOT be included in its own h= tag, although other DKIM-Signature
header fields MAY be signed (see Section 4).
When calculating the hash on messages that will be transmitted using When calculating the hash on messages that will be transmitted using
base64 or quoted-printable encoding, signers MUST compute the hash base64 or quoted-printable encoding, signers MUST compute the hash
after the encoding. Likewise, the verifier MUST incorporate the after the encoding. Likewise, the verifier MUST incorporate the
values into the hash before decoding the base64 or quoted-printable values into the hash before decoding the base64 or quoted-printable
text. However, the hash MUST be computed before transport level text. However, the hash MUST be computed before transport level
encodings such as SMTP "dot-stuffing." encodings such as SMTP "dot-stuffing."
With the exception of the canonicalization procedure described in With the exception of the canonicalization procedure described in
Section 3.4, the DKIM signing process treats the body of messages as Section 3.4, the DKIM signing process treats the body of messages as
skipping to change at page 32, line 11 skipping to change at page 32, line 37
identity MUST be the same as, or a subdomain of, the d= domain. Key identity MUST be the same as, or a subdomain of, the d= domain. Key
records which are not intended for use with subdomains SHOULD specify records which are not intended for use with subdomains SHOULD specify
the "s" flag in the t= tag. the "s" flag in the t= tag.
4. Semantics of Multiple Signatures 4. Semantics of Multiple Signatures
A signer that is adding a signature to a message merely creates a new A signer that is adding a signature to a message merely creates a new
DKIM-Signature header, using the usual semantics of the h= option. A DKIM-Signature header, using the usual semantics of the h= option. A
signer MAY sign previously existing DKIM-Signature header fields signer MAY sign previously existing DKIM-Signature header fields
using the method described in section Section 5.4 to sign trace using the method described in section Section 5.4 to sign trace
headers. Signers should be cognizant that signing DKIM-Signature header fields.
header fields may result in signature failures with intermediaries
that do not recognize that DKIM-Signature header fields are trace INFORMATIVE NOTE: Signers should be cognizant that signing DKIM-
header fields and unwittingly reorder them. Signature header fields may result in signature failures with
intermediaries that do not recognize that DKIM-Signature header
fields are trace header fields and unwittingly reorder them, thus
breaking such signatures.
INFORMATIVE NOTE: If a header field with multiple instances is
signed, those header fields are always signed from the bottom up.
Thus, it is not possible to sign only specific DKIM-Signature
header fields. For example, if the message being signed already
contains three DKIM-Signature header fields A, B, and C, it is
possible to sign all of them, B and C only, or C only, but not A
only, B only, A and B only, or A and C only.
When evaluating a message with multiple signatures, a verifier should When evaluating a message with multiple signatures, a verifier should
evaluate signatures independently and on their own merits. For evaluate signatures independently and on their own merits. For
example, a verifier that by policy chooses not to accept signatures example, a verifier that by policy chooses not to accept signatures
with deprecated cryptographic algorithms should consider such with deprecated cryptographic algorithms should consider such
signatures invalid. As with messages with a single signature, signatures invalid. As with messages with a single signature,
verifiers are at liberty to use the presence of valid signatures as verifiers are at liberty to use the presence of valid signatures as
an input to local policy; likewise, the interpretation of multiple an input to local policy; likewise, the interpretation of multiple
valid signatures in combination is a local policy decision of the valid signatures in combination is a local policy decision of the
verifier. verifier.
skipping to change at page 34, line 30 skipping to change at page 35, line 18
INFORMATIVE OPERATIONS NOTE: The choice of which header fields to INFORMATIVE OPERATIONS NOTE: The choice of which header fields to
sign is non-obvious. One strategy is to sign all existing, non- sign is non-obvious. One strategy is to sign all existing, non-
repeatable header fields. An alternative strategy is to sign only repeatable header fields. An alternative strategy is to sign only
header fields that are likely to be displayed to or otherwise be header fields that are likely to be displayed to or otherwise be
likely to affect the processing of the message at the receiver. A likely to affect the processing of the message at the receiver. A
third strategy is to sign only "well known" headers. Note that third strategy is to sign only "well known" headers. Note that
verifiers may treat unsigned header fields with extreme verifiers may treat unsigned header fields with extreme
skepticism, including refusing to display them to the end user or skepticism, including refusing to display them to the end user or
even ignore the signature if it does not cover certain header even ignore the signature if it does not cover certain header
fields. For this reason signing fields present in the message fields. For this reason signing fields present in the message
such as Date, Subject, Reply-To, Sender, and all MIME headers is such as Date, Subject, Reply-To, Sender, and all MIME header
highly advised. fields is highly advised.
The DKIM-Signature header field is always implicitly signed and MUST The DKIM-Signature header field is always implicitly signed and MUST
NOT be included in the h= tag except to indicate that other NOT be included in the h= tag except to indicate that other
preexisting signatures are also signed. preexisting signatures are also signed.
Signers MAY claim to have signed header fields that do not exist Signers MAY claim to have signed header fields that do not exist
(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
skipping to change at page 36, line 50 skipping to change at page 37, line 39
the Selector given in the "s=" tag of the "DKIM-Signature" header the Selector given in the "s=" tag of the "DKIM-Signature" header
field, as chosen above in Section 5.2 field, as chosen above in Section 5.2
The "DKIM-Signature" MUST be inserted before any other DKIM-Signature The "DKIM-Signature" MUST be inserted before any other DKIM-Signature
fields in the header block. fields in the header block.
INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this
is to insert the "DKIM-Signature" header field at the beginning of is to insert the "DKIM-Signature" header field at the beginning of
the header block. In particular, it may be placed before any the header block. In particular, it may be placed before any
existing Received header fields. This is consistent with treating existing Received header fields. This is consistent with treating
"DKIM-Signature" as a trace header. "DKIM-Signature" as a trace header field.
6. Verifier Actions 6. Verifier Actions
Since a signer MAY remove or revoke a public key at any time, it is Since a signer MAY remove or revoke a public key at any time, it is
recommended that verification occur in a timely manner with the most recommended that verification occur in a timely manner with the most
timely place being during acceptance by the border MTA. timely place being during acceptance by the border MTA.
A border or intermediate MTA MAY verify the message signature(s). An A border or intermediate MTA MAY verify the message signature(s). An
MTA who has performed verification MAY communicate the result of that MTA who has performed verification MAY communicate the result of that
verification by adding a verification header field to incoming verification by adding a verification header field to incoming
skipping to change at page 37, line 44 skipping to change at page 38, line 33
textual order, whereas another might want to prefer signatures by textual order, whereas another might want to prefer signatures by
identities that match the contents of the "From" header field over identities that match the contents of the "From" header field over
other identities. Verifiers MUST NOT attribute ultimate meaning to other identities. Verifiers MUST NOT attribute ultimate meaning to
the order of multiple DKIM-Signature header fields. In particular, the order of multiple DKIM-Signature header fields. In particular,
there is reason to believe that some relays will reorder the header there is reason to believe that some relays will reorder the header
fields in potentially arbitrary ways. fields in potentially arbitrary ways.
INFORMATIVE IMPLEMENTATION NOTE: Verifiers might use the order as INFORMATIVE IMPLEMENTATION NOTE: Verifiers might use the order as
a clue to signing order in the absence of any other information. a clue to signing order in the absence of any other information.
However, other clues as to the semantics of multiple signatures However, other clues as to the semantics of multiple signatures
(such as correlating the signing host with Received headers) may (such as correlating the signing host with Received header fields)
also be considered. may also be considered.
A verifier SHOULD NOT treat a message that has one or more bad A verifier SHOULD NOT treat a message that has one or more bad
signatures and no good signatures differently from a message with no signatures and no good signatures differently from a message with no
signature at all; such treatment is a matter of local policy and is signature at all; such treatment is a matter of local policy and is
beyond the scope of this document. beyond the scope of this document.
When a signature successfully verifies, a verifier will either stop When a signature successfully verifies, a verifier will either stop
processing or attempt to verify any other signatures, at the processing or attempt to verify any other signatures, at the
discretion of the implementation. A verifier MAY limit the number of discretion of the implementation. A verifier MAY limit the number of
signatures it tries to avoid denial-of-service attacks. signatures it tries to avoid denial-of-service attacks.
INFORMATIVE NOTE: An attacker could send messages with large INFORMATIVE NOTE: An attacker could send messages with large
numbers of faulty signatures, each of which would require a DNS numbers of faulty signatures, each of which would require a DNS
lookup. This could be an attack on the domain that receives the lookup and corresponding CPU time to verify the message. This
message, by slowing down the verifier by requiring it to do large could be an attack on the domain that receives the message, by
number of DNS lookups and signature verifications. It could also slowing down the verifier by requiring it to do large number of
be an attack against the domains listed in the signatures, DNS lookups and/or signature verifications. It could also be an
essentially by enlisting innocent verifiers in launching an attack attack against the domains listed in the signatures, essentially
against the DNS servers of the actual victim. by enlisting innocent verifiers in launching an attack against the
DNS servers of the actual victim.
In the following description, text reading "return status In the following description, text reading "return status
(explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL") (explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL")
means that the verifier MUST immediately cease processing that means that the verifier MUST immediately cease processing that
signature. The verifier SHOULD proceed to the next signature, if any signature. The verifier SHOULD proceed to the next signature, if any
is present, and completely ignore the bad signature. If the status is present, and completely ignore the bad signature. If the status
is "PERMFAIL", the signature failed and should not be reconsidered. is "PERMFAIL", the signature failed and should not be reconsidered.
If the status is "TEMPFAIL", the signature could not be verified at If the status is "TEMPFAIL", the signature could not be verified at
this time but may be tried again later. A verifier MAY either defer this time but may be tried again later. A verifier MAY either defer
the message for later processing, perhaps by queueing it locally or the message for later processing, perhaps by queueing it locally or
skipping to change at page 40, line 46 skipping to change at page 41, line 36
3. If the query for the public key fails because the corresponding 3. If the query for the public key fails because the corresponding
key record does not exist, the verifier MUST immediately return key record does not exist, the verifier MUST immediately return
PERMFAIL (no key for signature). PERMFAIL (no key for signature).
4. If the query for the public key returns multiple key records, the 4. If the query for the public key returns multiple key records, the
verifier may choose one of the key records or may cycle through verifier may choose one of the key records or may cycle through
the key records performing the remainder of these steps on each the key records performing the remainder of these steps on each
record at the discretion of the implementer. The order of the record at the discretion of the implementer. The order of the
key records is unspecified. If the verifier chooses to cycle key records is unspecified. If the verifier chooses to cycle
through the key records, then the "return with ..." wording in through the key records, then the "return ..." wording in the
the remainder of this section means "try the next key record, if remainder of this section means "try the next key record, if any;
any; if none, return to try another signature in the usual way." if none, return to try another signature in the usual way."
5. If the result returned from the query does not adhere to the 5. If the result returned from the query does not adhere to the
format defined in this specification, the verifier MUST ignore format defined in this specification, the verifier MUST ignore
the key record and return PERMFAIL (key syntax error). Verifiers the key record and return PERMFAIL (key syntax error). Verifiers
are urged to validate the syntax of key records carefully to are urged to validate the syntax of key records carefully to
avoid attempted attacks. avoid attempted attacks. In particular, the verifier MUST ignore
keys with a version code ("v=" tag) that they do not implement.
6. If the "g=" tag in the public key does not match the Local-part 6. If the "g=" tag in the public key does not match the Local-part
of the "i=" tag in the message signature header field, the of the "i=" tag in the message signature header field, the
verifier MUST ignore the key record and return PERMFAIL verifier MUST ignore the key record and return PERMFAIL
(inapplicable key). If the Local-part of the "i=" tag on the (inapplicable key). If the Local-part of the "i=" tag on the
message signature is not present, the g= tag must be * (valid for message signature is not present, the g= tag must be * (valid for
all addresses in the domain) or the entire g= tag must be omitted all addresses in the domain) or the entire g= tag must be omitted
(which defaults to "g=*"), otherwise the verifier MUST ignore the (which defaults to "g=*"), otherwise the verifier MUST ignore the
key record and return PERMFAIL (inapplicable key). Other than key record and return PERMFAIL (inapplicable key). Other than
this test, verifiers SHOULD NOT treat a message signed with a key this test, verifiers SHOULD NOT treat a message signed with a key
record having a g= tag any differently than one without; in record having a g= tag any differently than one without; in
particular, verifiers SHOULD NOT prefer messages that seem to particular, verifiers SHOULD NOT prefer messages that seem to
have an individual signature by virtue of a g= tag versus a have an individual signature by virtue of a g= tag versus a
domain signature. domain signature.
7. If the "h=" tag exists in the public key record and the hash 7. If the "h=" tag exists in the public key record and the hash
algorithm implied by the a= tag in the DKIM-Signature header is algorithm implied by the a= tag in the DKIM-Signature header
not included in the contents of the "h=" tag, the verifier MUST field is not included in the contents of the "h=" tag, the
ignore the key record and return PERMFAIL (inappropriate hash verifier MUST ignore the key record and return PERMFAIL
algorithm). (inappropriate hash algorithm).
8. If the public key data (the "p=" tag) is empty then this key has 8. If the public key data (the "p=" tag) is empty then this key has
been revoked and the verifier MUST treat this as a failed been revoked and the verifier MUST treat this as a failed
signature check and return PERMFAIL (key revoked). There is no signature check and return PERMFAIL (key revoked). There is no
defined semantic difference between a key that has been revoked defined semantic difference between a key that has been revoked
and a key record that has been removed. and a key record that has been removed.
9. If the public key data is not suitable for use with the algorithm 9. If the public key data is not suitable for use with the algorithm
and key types defined by the "a=" and "k=" tags in the "DKIM- and key types defined by the "a=" and "k=" tags in the "DKIM-
Signature" header field, the verifier MUST immediately return Signature" header field, the verifier MUST immediately return
skipping to change at page 42, line 11 skipping to change at page 42, line 49
actually need to be instantiated). When matching header field actually need to be instantiated). When matching header field
names in the "h=" tag against the actual message header field, names in the "h=" tag against the actual message header field,
comparisons MUST be case-insensitive. comparisons MUST be case-insensitive.
2. Based on the algorithm indicated in the "a=" tag, compute the 2. Based on the algorithm indicated in the "a=" tag, compute the
message hashes from the canonical copy as described in message hashes from the canonical copy as described in
Section 3.7. Section 3.7.
3. Verify that the hash of the canonicalized message body computed 3. Verify that the hash of the canonicalized message body computed
in the previous step matches the hash value conveyed in the "bh=" in the previous step matches the hash value conveyed in the "bh="
tag. tag. If the hash does not match, the verifier SHOULD ignore the
signature and return PERMFAIL (body hash did not verify).
4. Using the signature conveyed in the "b=" tag, verify the 4. Using the signature conveyed in the "b=" tag, verify the
signature against the header hash using the mechanism appropriate signature against the header hash using the mechanism appropriate
for the public key algorithm described in the "a=" tag. If the for the public key algorithm described in the "a=" tag. If the
signature does not validate, the verifier SHOULD ignore the signature does not validate, the verifier SHOULD ignore the
signature and return PERMFAIL (signature did not verify). signature and return PERMFAIL (signature did not verify).
5. Otherwise, the signature has correctly verified. 5. Otherwise, the signature has correctly verified.
INFORMATIVE IMPLEMENTER'S NOTE: Implementations might wish to INFORMATIVE IMPLEMENTER'S NOTE: Implementations might wish to
skipping to change at page 42, line 41 skipping to change at page 43, line 33
number of bytes of the body passed to the verification algorithm. number of bytes of the body passed to the verification algorithm.
All data beyond that limit is not validated by DKIM. Hence, All data beyond that limit is not validated by DKIM. Hence,
verifiers might treat a message that contains bytes beyond the verifiers might treat a message that contains bytes beyond the
indicated body length with suspicion, such as by truncating the indicated body length with suspicion, such as by truncating the
message at the indicated body length, declaring the signature invalid message at the indicated body length, declaring the signature invalid
(e.g., by returning PERMFAIL (unsigned content)), or conveying the (e.g., by returning PERMFAIL (unsigned content)), or conveying the
partial verification to the policy module. partial verification to the policy module.
INFORMATIVE IMPLEMENTATION NOTE: Verifiers that truncate the body INFORMATIVE IMPLEMENTATION NOTE: Verifiers that truncate the body
at the indicated body length might pass on a malformed MIME at the indicated body length might pass on a malformed MIME
message if the signer used the "N-4" trick described in the message if the signer used the "N-4" trick (omitting the final
informative note in Section 5.5. Such verifiers may wish to check "--CRLF") described in the informative note in Section 3.4.5.
for this case and include a trailing "--CRLF" to avoid breaking Such verifiers may wish to check for this case and include a
the MIME structure. A simple way to achieve this might be to trailing "--CRLF" to avoid breaking the MIME structure. A simple
append "--CRLF" to any "multipart" message with a body length; if way to achieve this might be to append "--CRLF" to any "multipart"
the MIME structure is already correctly formed, this will appear message with a body length; if the MIME structure is already
in the postlude and will not be displayed to the end user. correctly formed, this will appear in the postlude and will not be
displayed to the end user.
6.2 Communicate Verification Results 6.2 Communicate Verification Results
Verifiers wishing to communicate the results of verification to other Verifiers wishing to communicate the results of verification to other
parts of the mail system may do so in whatever manner they see fit. parts of the mail system may do so in whatever manner they see fit.
For example, implementations might choose to add an email header For example, implementations might choose to add an email header
field to the message before passing it on. Any such header field field to the message before passing it on. Any such header field
SHOULD be inserted before any existing DKIM-Signature or preexisting SHOULD be inserted before any existing DKIM-Signature or preexisting
authentication status header fields in the header field block. authentication status header fields in the header field block.
INFORMATIVE ADVICE to MUA filter writers: Patterns intended to INFORMATIVE ADVICE to MUA filter writers: Patterns intended to
search for results header fields to visibly mark authenticated search for results header fields to visibly mark authenticated
mail for end users should verify that such header field was added mail for end users should verify that such header field was added
by the appropriate verifying domain and that the verified identity by the appropriate verifying domain and that the verified identity
matches the author identity that will be displayed by the MUA. In matches the author identity that will be displayed by the MUA. In
particular, MUA filters should not be influenced by bogus results particular, MUA filters should not be influenced by bogus results
header fields added by attackers. Verifiers may wish to delete header fields added by attackers. To circumvent this attack,
existing results header fields after verification and before verifiers may wish to delete existing results header fields after
adding a new header field to circumvent this attack. verification and before adding a new header field.
6.3 Interpret Results/Apply Local Policy 6.3 Interpret Results/Apply Local Policy
It is beyond the scope of this specification to describe what actions It is beyond the scope of this specification to describe what actions
a verifier system should make, but an authenticated email presents an a verifier system should make, but an authenticated email presents an
opportunity to a receiving system that unauthenticated email cannot. opportunity to a receiving system that unauthenticated email cannot.
Specifically, an authenticated email creates a predictable identifier Specifically, an authenticated email creates a predictable identifier
by which other decisions can reliably be managed, such as trust and by which other decisions can reliably be managed, such as trust and
reputation. Conversely, unauthenticated email lacks a reliable reputation. Conversely, unauthenticated email lacks a reliable
identifier that can be used to assign trust and reputation. It is identifier that can be used to assign trust and reputation. It is
skipping to change at page 43, line 49 skipping to change at page 44, line 44
550 5.7.1 Unsigned messages not accepted 550 5.7.1 Unsigned messages not accepted
550 5.7.5 Message signature incorrect 550 5.7.5 Message signature incorrect
If it is not possible to fetch the public key, perhaps because the If it is not possible to fetch the public key, perhaps because the
key server is not available, a temporary failure message MAY be key server is not available, a temporary failure message MAY be
generated, such as: generated, such as:
451 4.7.5 Unable to verify signature - key server unavailable 451 4.7.5 Unable to verify signature - key server unavailable
A temporary failure of the key server or other external service is Temporary failures such as inability to access the key server or
the only condition that should use a 4xx SMTP reply code. In other external service are the only conditions that SHOULD use a 4xx
particular, signature verification failures MUST NOT return 4xx SMTP SMTP reply code. In particular, cryptographic signature verification
replies. failures MUST NOT return 4xx SMTP replies.
Once the signature has been verified, that information MUST be Once the signature has been verified, that information MUST be
conveyed to higher level systems (such as explicit allow/white lists conveyed to higher level systems (such as explicit allow/white lists
and reputation systems) and/or to the end user. If the message is and reputation systems) and/or to the end user. If the message is
signed on behalf of any address other than that in the From: header signed on behalf of any address other than that in the From: header
field, the mail system SHOULD take pains to ensure that the actual field, the mail system SHOULD take pains to ensure that the actual
signing identity is clear to the reader. signing identity is clear to the reader.
The verifier MAY treat unsigned header fields with extreme The verifier MAY treat unsigned header fields with extreme
skepticism, including marking them as untrusted or even deleting them skepticism, including marking them as untrusted or even deleting them
skipping to change at page 48, line 31 skipping to change at page 49, line 31
The initial entries in the registry comprise: The initial entries in the registry comprise:
+------+-----------------+ +------+-----------------+
| TYPE | REFERENCE | | TYPE | REFERENCE |
+------+-----------------+ +------+-----------------+
| y | (this document) | | y | (this document) |
| s | (this document) | | s | (this document) |
+------+-----------------+ +------+-----------------+
7.9 DKIM-Signature Header Field
IANA is requested to add DKIM-Signature to the "Permanent Header
Messages" registry for the "mail" protocol, using this document as
the Reference.
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 [RFC4686].
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
several potential attacks. several potential attacks.
8.1.1 Addition of new MIME parts to multipart/* 8.1.1 Addition of new MIME parts to multipart/*
If the body length limit does not cover a closing MIME multipart If the body length limit does not cover a closing MIME multipart
section (including the trailing ""--CRLF"" portion), then it is section (including the trailing ""--CRLF"" portion), then it is
skipping to change at page 50, line 49 skipping to change at page 52, line 9
Since DNS is a required binding for key services, specific attacks Since DNS is a required binding for key services, specific attacks
against DNS must be considered. against DNS must be considered.
While the DNS is currently insecure [RFC3833], it is expected that While the DNS is currently insecure [RFC3833], it is expected that
the security problems should and will be solved by DNSSEC [RFC4033], the security problems should and will be solved by DNSSEC [RFC4033],
and all users of the DNS will reap the benefit of that work. and all users of the DNS will reap the benefit of that work.
Secondly, the types of DNS attacks relevant to DKIM are very costly Secondly, the types of DNS attacks relevant to DKIM are very costly
and are far less rewarding than DNS attacks on other Internet and are far less rewarding than DNS attacks on other Internet
applications. protocols. For example, attacking A records (to force users to a
phishing site) is likely to be a more lucrative reason to poison DNS
caches. None the less, the security of DKIM is strongly tied to the
security of DNS.
To systematically thwart the intent of DKIM, an attacker must conduct To systematically thwart the intent of DKIM, an attacker must conduct
a very costly and very extensive attack on many parts of the DNS over a very costly and very extensive attack on many parts of the DNS over
an extended period. No one knows for sure how attackers will an extended period. No one knows for sure how attackers will
respond, however the cost/benefit of conducting prolonged DNS attacks respond, however the cost/benefit of conducting prolonged DNS attacks
of this nature is expected to be uneconomical. of this nature is expected to be uneconomical.
Finally, DKIM is only intended as a "sufficient" method of proving Finally, DKIM is only intended as a "sufficient" method of proving
authenticity. It is not intended to provide strong cryptographic authenticity. It is not intended to provide strong cryptographic
proof about authorship or contents. Other technologies such as proof about authorship or contents. Other technologies such as
skipping to change at page 52, line 39 skipping to change at page 54, line 5
by using a per-message Selector and then monitoring their DNS traffic by using a per-message Selector and then monitoring their DNS traffic
for the key lookup. This would act as the equivalent of a "web bug" for the key lookup. This would act as the equivalent of a "web bug"
for verification time rather than when the message was read. for verification time rather than when the message was read.
8.10 Remote Timing Attacks 8.10 Remote Timing Attacks
In some cases it may be possible to extract private keys using a In some cases it may be possible to extract private keys using a
remote timing attack [BONEH03]. Implementations should consider remote timing attack [BONEH03]. Implementations should consider
obfuscating the timing to prevent such attacks. obfuscating the timing to prevent such attacks.
8.11 Reordered Header Fields
Existing standards allow intermediate MTAs to reorder header fields.
If a signer signs two or more header fields of the same name, this
can cause spurious verification errors on otherwise legitimate
messages.
9. References 9. References
9.1 Normative References 9.1 Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message header field Extensions for Non-ASCII Part Three: Message header field Extensions for Non-ASCII
skipping to change at page 53, line 37 skipping to change at page 55, line 11
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.
9.2 Informative References 9.2 Informative References
[BONEH03] Proc. 12th USENIX Security Symposium, "Remote Timing [BONEH03] Proc. 12th USENIX Security Symposium, "Remote Timing
Attacks are Practical", 2003, <http://www.usenix.org/ Attacks are Practical", 2003, <http://www.usenix.org/
publications/library/proceedings/sec03/tech/brumley.html>. publications/library/proceedings/sec03/tech/brumley.html>.
[ID-DKIM-THREATS] [RFC-DK] "DomainKeys specification (to be published with this
Fenton, J., "Analysis of Threats Motivating DomainKeys RFC)", 2005.
Identified Mail (DKIM)", draft-fenton-dkim-threats-02
(work in progress), April 2006.
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and "Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995. Multipart/Encrypted", RFC 1847, October 1995.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998. "OpenPGP Message Format", RFC 2440, November 1998.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths for [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths for
Public Keys Used For Exchanging Symmetric Keys", RFC 3766, Public Keys Used For Exchanging Symmetric Keys", RFC 3766,
skipping to change at page 54, line 15 skipping to change at page 55, line 35
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004. Name System (DNS)", RFC 3833, August 2004.
[RFC3851] Ramsdell, B., "S/MIME Version 3 Message Specification", [RFC3851] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 3851, June 1999. RFC 3851, June 1999.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", RFC 4686, September 2006.
Authors' Addresses Authors' Addresses
Eric Allman Eric Allman
Sendmail, Inc. Sendmail, Inc.
6425 Christie Ave, Suite 400 6425 Christie Ave, Suite 400
Emeryville, CA 94608 Emeryville, CA 94608
USA USA
Phone: +1 510 594 5501 Phone: +1 510 594 5501
Email: eric+dkim@sendmail.org Email: eric+dkim@sendmail.org
skipping to change at page 56, line 24 skipping to change at page 58, line 8
Joe. Joe.
A.2 The email is signed A.2 The email is signed
This email is signed by the example.com outbound email server and now This email is signed by the example.com outbound email server and now
looks like this: looks like this:
DKIM-Signature: a=rsa-sha256; s=brisbane; d=example.com; DKIM-Signature: a=rsa-sha256; s=brisbane; d=example.com;
c=simple; q=dns/txt; i=joe@football.example.com; c=simple; q=dns/txt; i=joe@football.example.com;
h=Received : From : To : Subject : Date : Message-ID; h=Received : From : To : Subject : Date : Message-ID;
bh=ZSVEYuq4ri3LR9S+qjlzCP+LxvJrIfrOI2g5hxp5+MI=; bh=jpltwNFTq83Bkjt/Y2ekyqr/+i296daNkFZSdaz8VCY=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ b=bnUoMBPJ5wBigyZG2V4OG2JxLWJATkSkb9Ig+8OAu3cE2x/er+B
VoG4ZHRNiYzR; 7Tp1a1kEwZKdOtlTHlvF4JKg6RZUbN5urRJoaiD4RiSbf8D6fmMHt
zEn8/OHpTCcdLOJaTp8/mKz69/RpatVBas2OqWas7jrlaLGfHdBkt
Hs6fxOzzAB7Wro=;
Received: from dsl-10.2.3.4.football.example.com [10.2.3.4] Received: from dsl-10.2.3.4.football.example.com [10.2.3.4]
by submitserver.example.com with SUBMISSION; by submitserver.example.com with SUBMISSION;
Fri, 11 Jul 2003 21:01:54 -0700 (PDT) Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <joe@football.example.com> From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net> To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready? Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com> Message-ID: <20030712040037.46341.5F8J@football.example.com>
Hi. Hi.
skipping to change at page 57, line 15 skipping to change at page 58, line 47
"d=" tag and the Selector "brisbane" from the "s=" tag in the "DKIM- "d=" tag and the Selector "brisbane" from the "s=" tag in the "DKIM-
Signature" header field to form the DNS DKIM query for: Signature" header field to form the DNS DKIM query for:
brisbane._domainkey.example.com brisbane._domainkey.example.com
Signature verification starts with the physically last "Received" Signature verification starts with the physically last "Received"
header field, the "From" header field, and so forth, in the order header field, the "From" header field, and so forth, in the order
listed in the "h=" tag. Verification follows with a single CRLF listed in the "h=" tag. Verification follows with a single CRLF
followed by the body (starting with "Hi."). The email is canonically followed by the body (starting with "Hi."). The email is canonically
prepared for verifying with the "simple" method. The result of the prepared for verifying with the "simple" method. The result of the
query and subsequent verification of the signature is stored in the query and subsequent verification of the signature is stored (in this
"Authentication-Results" header field line. After successful example) in the "X-Authentication-Results" header field line. After
verification, the email looks like this: successful verification, the email looks like this:
X-Authentication-Results: shopping.example.net X-Authentication-Results: shopping.example.net
header.from=joe@football.example.com; dkim=pass header.from=joe@football.example.com; dkim=pass
Received: from mout23.football.example.com (192.168.1.1) Received: from mout23.football.example.com (192.168.1.1)
by shopping.example.net with SMTP; by shopping.example.net with SMTP;
Fri, 11 Jul 2003 21:01:59 -0700 (PDT) Fri, 11 Jul 2003 21:01:59 -0700 (PDT)
DKIM-Signature: a=rsa-sha256; s=brisbane; d=example.com; DKIM-Signature: a=rsa-sha256; s=brisbane; d=example.com;
c=simple; q=dns/txt; i=joe@football.example.com; c=simple; q=dns/txt; i=joe@football.example.com;
h=Received : From : To : Subject : Date : Message-ID; h=Received : From : To : Subject : Date : Message-ID;
bh=ZSVEYuq4ri3LR9S+qjlzCP+LxvJrIfrOI2g5hxp5+MI=; bh=jpltwNFTq83Bkjt/Y2ekyqr/+i296daNkFZSdaz8VCY=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ b=bnUoMBPJ5wBigyZG2V4OG2JxLWJATkSkb9Ig+8OAu3cE2x/er+B
VoG4ZHRNiYzR 7Tp1a1kEwZKdOtlTHlvF4JKg6RZUbN5urRJoaiD4RiSbf8D6fmMHt
zEn8/OHpTCcdLOJaTp8/mKz69/RpatVBas2OqWas7jrlaLGfHdBkt
Hs6fxOzzAB7Wro=;
Received: from dsl-10.2.3.4.network.example.com [10.2.3.4] Received: from dsl-10.2.3.4.network.example.com [10.2.3.4]
by submitserver.example.com with SUBMISSION; by submitserver.example.com with SUBMISSION;
Fri, 11 Jul 2003 21:01:54 -0700 (PDT) Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <joe@football.example.com> From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net> To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready? Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com> Message-ID: <20030712040037.46341.5F8J@football.example.com>
Hi. Hi.
skipping to change at page 64, line 35 skipping to change at page 66, line 14
present this information to the user in a way that helps them is a present this information to the user in a way that helps them is a
matter of continuing human factors usability research. The tendency matter of continuing human factors usability research. The tendency
is to have the MUA highlight the address associated with this signing is to have the MUA highlight the address associated with this signing
identity in some way, in an attempt to show the user the address from identity in some way, in an attempt to show the user the address from
which the mail was sent. An MUA might do this with visual cues such which the mail was sent. An MUA might do this with visual cues such
as graphics, or it might include the address in an alternate view, or as graphics, or it might include the address in an alternate view, or
it might even rewrite the original "From:" address using the verified it might even rewrite the original "From:" address using the verified
information. Some MUAs might indicate which header fields were information. Some MUAs might indicate which header fields were
protected by the validated DKIM signature. This could be done with a protected by the validated DKIM signature. This could be done with a
positive indication on the signed header fields, or with a negative positive indication on the signed header fields, or with a negative
indication on the unsigned headers or by visually hiding the unsigned indication on the unsigned header fields or by visually hiding the
headers, or some combination of these. If an MUA uses visual unsigned header fields, or some combination of these. If an MUA uses
indications for signed headers, the MUA probably needs to be careful visual indications for signed header fields, the MUA probably needs
not to display unsigned headers in a way that might be construed by to be careful not to display unsigned header fields in a way that
the end user as having been signed. If the message has an l= tag might be construed by the end user as having been signed. If the
whose value does not extend to the end of the message, the MUA might message has an l= tag whose value does not extend to the end of the
also hide or mark the portion of the message body that was not message, the MUA might also hide or mark the portion of the message
signed. body that was not signed.
The aforementioned information is not intended to be exhaustive. The The aforementioned information is not intended to be exhaustive. The
MUA may choose to highlight, accentuate, hide, or otherwise display MUA may choose to highlight, accentuate, hide, or otherwise display
any other information that may, in the opinion of the MUA author, be any other information that may, in the opinion of the MUA author, be
deemed important to the end user. deemed important to the end user.
Appendix E. Acknowledgements Appendix E. Acknowledgements
The authors wish to thank Russ Allbery, Edwin Aoki, Claus Assmann, The authors wish to thank Russ Allbery, Edwin Aoki, Claus Assmann,
Steve Atkins, Fred Baker, Mark Baugher, Steve Bellovin, Nathaniel Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve Bellovin,
Borenstein, Dave Crocker, Michael Cudahy, Dennis Dayman, Jutta Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis Dayman,
Degener, Patrik Faltstrom, Mark Fanto, Stephen Farrell, Duncan Jutta Degener, Patrik Faltstrom, Mark Fanto, Stephen Farrell, Duncan
Findlay, Elliot Gillum, Phillip Hallam-Baker, Tony Hansen, Sam Findlay, Elliot Gillum, Phillip Hallam-Baker, Tony Hansen, Sam
Hartman, Arvel Hathcock, Amir Herzberg, Paul Hoffman, Russ Housley, Hartman, Arvel Hathcock, Amir Herzberg, Paul Hoffman, Russ Housley,
Craig Hughes, Don Johnsen, Harry Katz, Murray S. Kucherawy, Barry Craig Hughes, Don Johnsen, Harry Katz, Murray S. Kucherawy, Barry
Leiba, John Levine, Simon Longsdale, David Margrave, Justin Mason, Leiba, John Levine, Simon Longsdale, David Margrave, Justin Mason,
David Mayne, Steve Murphy, Russell Nelson, Dave Oran, Doug Otis, David Mayne, Steve Murphy, Russell Nelson, Dave Oran, Doug Otis,
Shamim Pirzada, Juan Altmayer Pizzorno, Sanjay Pol, Blake Ramsdell, Shamim Pirzada, Juan Altmayer Pizzorno, Sanjay Pol, Blake Ramsdell,
Christian Renaud, Scott Renfro, Neil Rerup, Eric Rescorla, Dave Christian Renaud, Scott Renfro, Neil Rerup, Eric Rescorla, Dave
Rossetti, Hector Santos, Jim Schaad, the Spamhaus.org team, Malte S. Rossetti, Hector Santos, Jim Schaad, the Spamhaus.org team, Malte S.
Stretz, Robert Sanders, Rand Wacker, Sam Weiler, and Dan Wing for Stretz, Robert Sanders, Rand Wacker, Sam Weiler, and Dan Wing for
their valuable suggestions and constructive criticism. their valuable suggestions and constructive criticism.
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 [RFC-DK].
<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-05 version F.1 Changes since -ietf-06 version
The following changes were made between draft-ietf-dkim-base-06 and
draft-ietf-dkim-base-07:
o Added section 8.11 regarding header reordering.
o Added informative note to section 3.3 regarding use of sha256.
o Added informative rationale to section 3.6.1, "p=", regarding key
revocation.
o Added second informative note in section 4 regarding signing
multiple DKIM-Signature header fields.
o Minor modification of the second informative note in section 6.1
regarding DoS attacks.
o Added explicit mention of v= to section 6.1.2, step 5.
o Updated paragraph 3 of section 8.4 regarding DNS attacks.
o Added section 7.9 (DKIM-Signature IANA Registry) per IANA request.
F.2 Changes since -ietf-05 version
The following changes were made between draft-ietf-dkim-base-05 and The following changes were made between draft-ietf-dkim-base-05 and
draft-ietf-dkim-base-06: draft-ietf-dkim-base-06:
o Fix an error in an example in Appendix C. o Fix an error in an example in Appendix C.
o Substantial updates to Appendixes B and D. o Substantial updates to Appendixes B and D.
o Clarify ABNF for tag-value. o Clarify ABNF for tag-value.
skipping to change at page 66, line 7 skipping to change at page 68, line 7
o Add normative reference to SHA1/SHA256 FIPS publication 180-2. o Add normative reference to SHA1/SHA256 FIPS publication 180-2.
o Several minor edits based on AD Review. o Several minor edits based on AD Review.
o Move discussion of not re-using a selector (i.e., changing the o Move discussion of not re-using a selector (i.e., changing the
public key for a single selector) from informational to normative. public key for a single selector) from informational to normative.
o Assorted wordsmithing based on external review. o Assorted wordsmithing based on external review.
F.2 Changes since -ietf-04 version F.3 Changes since -ietf-04 version
The following changes were made between draft-ietf-dkim-base-04 and The following changes were made between draft-ietf-dkim-base-04 and
draft-ietf-dkim-base-05: draft-ietf-dkim-base-05:
o Clarified definition of "plain text" in section 3.2 (issue 1316). o Clarified definition of "plain text" in section 3.2 (issue 1316).
o Added some clarification about multiple listings of non-existent o Added some clarification about multiple listings of non-existent
header field names in h= in section 5.4 (issue 1316). header field names in h= in section 5.4 (issue 1316).
o Finished filling out IANA registries in section 7 (issue 1320). o Finished filling out IANA registries in section 7 (issue 1320).
skipping to change at page 66, line 29 skipping to change at page 68, line 29
o Clarified handling of bare CR and LF in section 5.3 (issue 1326). 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 o Listed the required tags in section 6.1.1 as an informational note
(issue 1330). (issue 1330).
o Changed IDNA reference from 3492 to 3490 (issue 1331). o Changed IDNA reference from 3492 to 3490 (issue 1331).
o Changed the reference for WSP to 4234; changed the definition of o Changed the reference for WSP to 4234; changed the definition of
SWSP to exclude bare CR and LF (issue 1332). SWSP to exclude bare CR and LF (issue 1332).
F.3 Changes since -ietf-03 version F.4 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 67, line 38 skipping to change at page 69, line 38
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.4 Changes since -ietf-02 version F.5 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 68, line 39 skipping to change at page 70, line 39
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.5 Changes since -ietf-01 version F.6 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 69, line 21 skipping to change at page 71, line 21
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.6 Changes since -ietf-00 version F.7 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 69, line 45 skipping to change at page 71, line 45
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.7 Changes since -allman-01 version F.8 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.8 Changes since -allman-00 version F.9 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. 65 change blocks. 
173 lines changed or deleted 250 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/