draft-ietf-dkim-rfc4871bis-10.txt   draft-ietf-dkim-rfc4871bis-11.txt 
Network Working Group D. Crocker, Ed. Network Working Group D. Crocker, Ed.
Internet-Draft Brandenburg InternetWorking Internet-Draft Brandenburg InternetWorking
Obsoletes: 4871, 5672 T. Hansen, Ed. Obsoletes: 4871, 5672 T. Hansen, Ed.
(if approved) AT&T Laboratories (if approved) AT&T Laboratories
Intended status: Standards Track M. Kucherawy, Ed. Intended status: Standards Track M. Kucherawy, Ed.
Expires: November 12, 2011 Cloudmark Expires: December 17, 2011 Cloudmark
May 11, 2011 June 15, 2011
DomainKeys Identified Mail (DKIM) Signatures DomainKeys Identified Mail (DKIM) Signatures
draft-ietf-dkim-rfc4871bis-10 draft-ietf-dkim-rfc4871bis-11
Abstract Abstract
DomainKeys Identified Mail (DKIM) permits a person, role, or DomainKeys Identified Mail (DKIM) permits a person, role, or
organization that owns the signing domain to claim some organization that owns the signing domain to claim some
responsibility for a message by associating the domain with the responsibility for a message by associating the domain with the
message. This can be an author's organization, an operational relay message. This can be an author's organization, an operational relay
or one of their agents. DKIM separates the question of the identity or one of their agents. DKIM separates the question of the identity
of the signer of the message from the purported author of the of the signer of the message from the purported author of the
message. Assertion of responsibility is validated through a message. Assertion of responsibility is validated through a
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on November 12, 2011. This Internet-Draft will expire on December 17, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 42 skipping to change at page 2, line 42
2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 8 2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 8
2.9. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 9 2.9. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 9
2.10. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 9 2.10. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 9
2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 10 2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 10
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 11 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 13 3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 13
3.3. Signing and Verification Algorithms . . . . . . . . . . . 14 3.3. Signing and Verification Algorithms . . . . . . . . . . . 14
3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15 3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15
3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 19 3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 19
3.6. Key Management and Representation . . . . . . . . . . . . 28 3.6. Key Management and Representation . . . . . . . . . . . . 29
3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33 3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33
3.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 35 3.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 36
3.9. Output Requirements . . . . . . . . . . . . . . . . . . . 35 3.9. Output Requirements . . . . . . . . . . . . . . . . . . . 36
3.10. Signing by Parent Domains . . . . . . . . . . . . . . . . 36 3.10. Signing by Parent Domains . . . . . . . . . . . . . . . . 36
3.11. Relationship between SDID and AUID . . . . . . . . . . . . 36 3.11. Relationship between SDID and AUID . . . . . . . . . . . . 36
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 37 4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 37
4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 37 4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 37
4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 38 4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 39
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 39 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 40
5.1. Determine Whether the Email Should Be Signed and by 5.1. Determine Whether the Email Should Be Signed and by
Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2. Select a Private Key and Corresponding Selector 5.2. Select a Private Key and Corresponding Selector
Information . . . . . . . . . . . . . . . . . . . . . . . 40 Information . . . . . . . . . . . . . . . . . . . . . . . 40
5.3. Normalize the Message to Prevent Transport Conversions . . 40 5.3. Normalize the Message to Prevent Transport Conversions . . 41
5.4. Determine the Header Fields to Sign . . . . . . . . . . . 41 5.4. Determine the Header Fields to Sign . . . . . . . . . . . 42
5.5. Recommended Signature Content . . . . . . . . . . . . . . 43 5.5. Recommended Signature Content . . . . . . . . . . . . . . 44
5.6. Compute the Message Hash and Signature . . . . . . . . . . 45 5.6. Compute the Message Hash and Signature . . . . . . . . . . 45
5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 45 5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 46
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 46 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 46
6.1. Extract Signatures from the Message . . . . . . . . . . . 46 6.1. Extract Signatures from the Message . . . . . . . . . . . 47
6.2. Communicate Verification Results . . . . . . . . . . . . . 51 6.2. Communicate Verification Results . . . . . . . . . . . . . 52
6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 52 6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 52
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 53 7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 54
7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 54 7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 54
7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 54 7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 55
7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 55 7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 56
7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 56 7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 56
7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 56 7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 56
7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 56 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 57
7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 57 7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 57
7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 57 7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 58
8. Security Considerations . . . . . . . . . . . . . . . . . . . 57 8. Security Considerations . . . . . . . . . . . . . . . . . . . 58
8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 57 8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 58
8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 58 8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 58
8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 58 8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 59
8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59 8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59
8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 59 8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 60
8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 60 8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 60
8.7. Intentionally Malformed Key Records . . . . . . . . . . . 60 8.7. Intentionally Malformed Key Records . . . . . . . . . . . 61
8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 60 8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 61
8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 61 8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 61
8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 61 8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 61
8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 61 8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 61
8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 61 8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 61
8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 61 8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 62
8.14. Attacks Involving Addition of Header Fields . . . . . . . 62 8.14. Attacks Involving Addition of Header Fields . . . . . . . 62
8.15. Malformed Inputs . . . . . . . . . . . . . . . . . . . . . 62 8.15. Malformed Inputs . . . . . . . . . . . . . . . . . . . . . 63
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64
9.1. Normative References . . . . . . . . . . . . . . . . . . . 63 9.1. Normative References . . . . . . . . . . . . . . . . . . . 64
9.2. Informative References . . . . . . . . . . . . . . . . . . 64 9.2. Informative References . . . . . . . . . . . . . . . . . . 65
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 66 Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 66
A.1. The User Composes an Email . . . . . . . . . . . . . . . . 66 A.1. The User Composes an Email . . . . . . . . . . . . . . . . 66
A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 66 A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 67
A.3. The Email Signature is Verified . . . . . . . . . . . . . 67 A.3. The Email Signature is Verified . . . . . . . . . . . . . 68
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 68 Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 69
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 69 B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 69
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 71 B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 71
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 73 Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 73
C.1. Compatibility with DomainKeys Key Records . . . . . . . . 74 C.1. Compatibility with DomainKeys Key Records . . . . . . . . 74
Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 74 Appendix D. MUA Considerations (INFORMATIVE) . . . . . . . . . . 74
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 75 Appendix E. Changes since RFC4871 . . . . . . . . . . . . . . . . 75
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77
1. Introduction 1. Introduction
DomainKeys Identified Mail (DKIM) permits a person, role, or DomainKeys Identified Mail (DKIM) permits a person, role, or
organization to claim some responsibility for a message by organization to claim some responsibility for a message by
associating a domain name [RFC1034] with the message [RFC5322], which associating a domain name [RFC1034] with the message [RFC5322], which
they are authorized to use. This can be an author's organization, an they are authorized to use. This can be an author's organization, an
operational relay or one of their agents. Assertion of operational relay or one of their agents. Assertion of
responsibility is validated through a cryptographic signature and responsibility is validated through a cryptographic signature and
querying the signer's domain directly to retrieve the appropriate querying the signer's domain directly to retrieve the appropriate
skipping to change at page 7, line 25 skipping to change at page 7, line 25
This section defines terms used in the rest of the document. This section defines terms used in the rest of the document.
DKIM is designed to operate within the Internet Mail service, as DKIM is designed to operate within the Internet Mail service, as
defined in [RFC5598]. Basic email terminology is taken from that defined in [RFC5598]. Basic email terminology is taken from that
specification. specification.
Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. Syntax descriptions use Augmented BNF (ABNF) [RFC5234].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. These "OPTIONAL" in this document are to be interpreted as described in
words take their normative meanings only when they are presented in [RFC2119]. These words take their normative meanings only when they
ALL UPPER CASE. are presented in ALL UPPER CASE.
2.1. Signers 2.1. Signers
Elements in the mail system that sign messages on behalf of a domain Elements in the mail system that sign messages on behalf of a domain
are referred to as signers. These may be MUAs (Mail User Agents), are referred to as signers. These may be MUAs (Mail User Agents),
MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents), or other MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents), or other
agents such as mailing list exploders. In general, any signer will agents such as mailing list exploders. In general, any signer will
be involved in the injection of a message into the message system in be involved in the injection of a message into the message system in
some way. The key issue is that a message must be signed before it some way. The key issue is that a message must be signed before it
leaves the administrative domain of the signer. leaves the administrative domain of the signer.
skipping to change at page 8, line 26 skipping to change at page 8, line 26
2.6. Agent or User Identifier (AUID) 2.6. Agent or User Identifier (AUID)
A single identifier that refers to the agent or user on behalf of A single identifier that refers to the agent or user on behalf of
whom the Signing Domain Identifier (SDID) has taken responsibility. whom the Signing Domain Identifier (SDID) has taken responsibility.
The AUID comprises a domain name and an optional <Local-part>. The The AUID comprises a domain name and an optional <Local-part>. The
domain name is the same as that used for the SDID or is a sub-domain domain name is the same as that used for the SDID or is a sub-domain
of it. For DKIM processing, the domain name portion of the AUID has of it. For DKIM processing, the domain name portion of the AUID has
only basic domain name semantics; any possible owner-specific only basic domain name semantics; any possible owner-specific
semantics are outside the scope of DKIM. It is specified in semantics are outside the scope of DKIM. It is specified in
Section 3.5 . Section 3.5.
Note the constraint on the value of "i=" that can be imposed by the Note the constraint on the value of "i=" that can be imposed by the
"t=s" tag of the stored key record. (See Section 3.6.1.) "t=s" tag of the stored key record. (See Section 3.6.1.)
2.7. Identity Assessor 2.7. Identity Assessor
A module that consumes DKIM's mandatory payload, which is the A module that consumes DKIM's mandatory payload, which is the
responsible Signing Domain Identifier (SDID). The module is responsible Signing Domain Identifier (SDID). The module is
dedicated to the assessment of the delivered identifier. Other DKIM dedicated to the assessment of the delivered identifier. Other DKIM
(and non-DKIM) values can also be delivered to this module as well as (and non-DKIM) values can also be delivered to this module as well as
skipping to change at page 10, line 25 skipping to change at page 10, line 25
Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded
as an "=" followed by two hexadecimal digits from the alphabet as an "=" followed by two hexadecimal digits from the alphabet
"0123456789ABCDEF" (no lowercase characters permitted) representing "0123456789ABCDEF" (no lowercase characters permitted) representing
the hexadecimal-encoded integer value of that character. All control the hexadecimal-encoded integer value of that character. All control
characters (those with values < %x20), 8-bit characters (values > characters (those with values < %x20), 8-bit characters (values >
%x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon %x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon
(";", %x3B) MUST be encoded. Note that all whitespace, including (";", %x3B) MUST be encoded. Note that all whitespace, including
SPACE, CR, and LF characters, MUST be encoded. After encoding, FWS SPACE, CR, and LF characters, MUST be encoded. After encoding, FWS
MAY be added at arbitrary locations in order to avoid excessively MAY be added at arbitrary locations in order to avoid excessively
long lines; such whitespace is NOT part of the value, and MUST be long lines; such whitespace is NOT part of the value, and MUST be
removed before decoding. removed before decoding. Use of characters not listed as "mail-safe"
in [RFC2049] is NOT RECOMMENDED.
ABNF: ABNF:
dkim-quoted-printable = *(FWS / hex-octet / dkim-safe-char) dkim-quoted-printable = *(FWS / hex-octet / dkim-safe-char)
; hex-octet is from RFC2045 ; hex-octet is from RFC2045
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
; [RFC2049] are also not recommended. ; [RFC2049] are also NOT RECOMMENDED.
INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted- INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted-
Printable as defined in [RFC2045] in several important ways: Printable as defined in [RFC2045] in several important ways:
1. Whitespace in the input text, including CR and LF, must be 1. Whitespace in the input text, including CR and LF, must be
encoded. [RFC2045] does not require such encoding, and does encoded. [RFC2045] does not require such encoding, and does
not permit encoding 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. Whitespace in the encoded text is ignored. This is to allow 2. Whitespace in the encoded text is ignored. This is to allow
skipping to change at page 14, line 27 skipping to change at page 14, line 27
INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged, some INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged, some
senders might prefer to use rsa-sha1 when balancing security senders might prefer to use rsa-sha1 when balancing security
strength against performance, complexity, or other needs. In strength against performance, complexity, or other needs. In
general, however, rsa-sha256 should always be used whenever general, however, rsa-sha256 should always be used whenever
possible. 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 [FIPS-180-2-2002] as the hash-alg. in Section 3.7 below using SHA-1 [FIPS-180-3-2008] as the hash-alg.
That hash is then signed by the signer using the RSA algorithm That hash is then signed by the signer using the RSA algorithm
(defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the (defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the
signer's private key. The hash MUST NOT be truncated or converted signer's private key. The hash MUST NOT be truncated or converted
into any form other than the native binary form before being signed. into any form other than the native binary form before being signed.
The signing algorithm SHOULD use a public exponent of 65537. The signing algorithm SHOULD use a public exponent of 65537.
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 [FIPS-180-2-2002] as the hash-alg. in Section 3.7 below using SHA-256 [FIPS-180-3-2008] as the hash-alg.
That hash is then signed by the signer using the RSA algorithm That hash is then signed by the signer using the RSA algorithm
(defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the (defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the
signer's private key. The hash MUST NOT be truncated or converted signer's private key. The hash MUST NOT be truncated or converted
into any form other than the native binary form before being signed. into any form other than the native binary form before being signed.
The signing algorithm SHOULD use a public exponent of 65537.
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 17, line 18 skipping to change at page 17, line 22
at the end of the message body. An empty line is a line of zero at the end of the message body. An empty line is a line of zero
length after removal of the line terminator. If there is no body or length after removal of the line terminator. If there is no body or
no trailing CRLF on the message body, a CRLF is added. It makes no no trailing CRLF on the message body, a CRLF is added. It makes no
other changes to the message body. In more formal terms, the other changes to the message body. In more formal terms, the
"simple" body canonicalization algorithm converts "0*CRLF" at the end "simple" body canonicalization algorithm converts "0*CRLF" at the end
of the body to a single "CRLF". of the body to a single "CRLF".
Note that a completely empty or missing body is canonicalized as a Note that a completely empty or missing body is canonicalized as a
single "CRLF"; that is, the canonicalized length will be 2 octets. single "CRLF"; that is, the canonicalized length will be 2 octets.
The sha1 value (in base64) for an empty body (canonicalized to a The SHA-1 value (in base64) for an empty body (canonicalized to a
"CRLF") is: "CRLF") is:
uoq1oCgLlTqpdDX/iUbLy7J1Wic= uoq1oCgLlTqpdDX/iUbLy7J1Wic=
The sha256 value is: The SHA-256 value is:
frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY= frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=
3.4.4. The "relaxed" Body Canonicalization Algorithm 3.4.4. The "relaxed" Body Canonicalization Algorithm
The "relaxed" body canonicalization algorithm MUST apply the The "relaxed" body canonicalization algorithm MUST apply the
following steps (a) and (b) in order: following steps (a) and (b) in order:
a. Reduce whitespace: a. Reduce whitespace:
* Ignore all whitespace at the end of lines. Implementations * Ignore all whitespace at the end of lines. Implementations
skipping to change at page 17, line 43 skipping to change at page 17, line 47
* Reduce all sequences of WSP within a line to a single SP * Reduce all sequences of WSP within a line to a single SP
character. character.
b. Ignore all empty lines at the end of the message body. "Empty b. Ignore all empty lines at the end of the message body. "Empty
line" is defined in Section 3.4.3. If the body is non-empty, but line" is defined in Section 3.4.3. If the body is non-empty, but
does not end with a CRLF, a CRLF is added. (For email, this is does not end with a CRLF, a CRLF is added. (For email, this is
only possible when using extensions to SMTP or non-SMTP transport only possible when using extensions to SMTP or non-SMTP transport
mechanisms.) mechanisms.)
The sha1 value (in base64) for an empty body (canonicalized to a null The SHA-1 value (in base64) for an empty body (canonicalized to a
input) is: null input) is:
2jmj7l5rSw0yVb/vlWAYkK/YBwk= 2jmj7l5rSw0yVb/vlWAYkK/YBwk=
The sha256 value is: The SHA-256 value is:
47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
INFORMATIVE NOTE: It should be noted that the relaxed body INFORMATIVE NOTE: It should be noted that the relaxed body
canonicalization algorithm may enable certain types of extremely canonicalization algorithm may enable certain types of extremely
crude "ASCII Art" attacks where a message may be conveyed by crude "ASCII Art" attacks where a message may be conveyed by
adjusting the spacing between words. If this is a concern, the adjusting the spacing between words. If this is a concern, the
"simple" body canonicalization algorithm should be used instead. "simple" body canonicalization algorithm should be used instead.
3.4.5. Body Length Limits 3.4.5. Body Length Limits
A body length count MAY be specified to limit the signature A body length count MAY be specified to limit the signature
calculation to an initial prefix of the body text, measured in calculation to an initial prefix of the body text, measured in
skipping to change at page 24, line 11 skipping to change at page 24, line 23
Internationalized domain names MUST be encoded as A-Labels, as Internationalized domain names MUST be encoded as A-Labels, as
described in Section 2.3 of [RFC5890]. described in Section 2.3 of [RFC5890].
ABNF: ABNF:
sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ]
"@" domain-name "@" domain-name
The AUID is specified as having the same syntax as an email The AUID is specified as having the same syntax as an email
address, but is not required to have the same semantics. Notably, address, but need not have the same semantics. Notably, the
the domain name is not required to be registered in the DNS -- so domain name is need not be registered in the DNS -- so it might
it might not resolve in a query -- and the Local-part MAY be drawn not resolve in a query -- and the Local-part MAY be drawn from a
from a namespace unrelated to any mailbox. The details of the namespace unrelated to any mailbox. The details of the structure
structure and semantics for the namespace are determined by the and semantics for the namespace are determined by the Signer. Any
Signer. Any knowledge or use of those details by verifiers or knowledge or use of those details by verifiers or assessors is
assessors is outside the scope of the DKIM Signing specification. outside the scope of the DKIM Signing specification. The Signer
The Signer MAY choose to use the same namespace for its AUIDs as MAY choose to use the same namespace for its AUIDs as its users'
its users' email addresses or MAY choose other means of email addresses or MAY choose other means of representing its
representing its users. However, the signer SHOULD use the same users. However, the signer SHOULD use the same AUID for each
AUID for each message intended to be evaluated as being within the message intended to be evaluated as being within the same sphere
same sphere of responsibility, if it wishes to offer receivers the of responsibility, if it wishes to offer receivers the option of
option of using the AUID as a stable identifier that is finer using the AUID as a stable identifier that is finer grained than
grained than the SDID. the SDID.
INFORMATIVE NOTE: The Local-part of the "i=" tag is optional INFORMATIVE NOTE: The Local-part of the "i=" tag is optional
because in some cases a signer may not be able to establish a because in some cases a signer may not be able to establish a
verified individual identity. In such cases, the signer might verified individual identity. In such cases, the signer might
wish to assert that although it is willing to go as far as wish to assert that although it is willing to go as far as
signing for the domain, it is unable or unwilling to commit to signing for the domain, it is unable or unwilling to commit to
an individual user name within their domain. It can do so by an individual user name within their domain. It can do so by
including the domain part but not the Local-part of the including the domain part but not the Local-part of the
identity. identity.
skipping to change at page 29, line 37 skipping to change at page 30, line 14
v= Version of the DKIM key record (plain-text; RECOMMENDED, default v= Version of the DKIM key record (plain-text; RECOMMENDED, default
is "DKIM1"). If specified, this tag MUST be set to "DKIM1" is "DKIM1"). If specified, this tag MUST be set to "DKIM1"
(without the quotes). This tag MUST be the first tag in the (without the quotes). This tag MUST be the first tag in the
record. Records beginning with a "v=" tag with any other value record. Records beginning with a "v=" tag with any other value
MUST be discarded. Note that verifiers must do a string MUST be discarded. Note that verifiers must do a string
comparison on this value; for example, "DKIM1" is not the same as comparison on this value; for example, "DKIM1" is not the same as
"DKIM1.0". "DKIM1.0".
ABNF: ABNF:
key-v-tag = %x76 [FWS] "=" [FWS] %x44 %x4B %x49 %x4D %x31 key-v-tag = %x76 [FWS] "=" [FWS] %x44.4B.49.4D.31
h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
allowing all algorithms). A colon-separated list of hash allowing all algorithms). A colon-separated list of hash
algorithms that might be used. Unrecognized algorithms MUST be algorithms that might be used. Unrecognized algorithms MUST be
ignored. Refer to Section 3.3 for a discussion of the hash ignored. Refer to Section 3.3 for a discussion of the hash
algorithms implemented by Signers and Verifiers. The set of algorithms implemented by Signers and Verifiers. The set of
algorithms listed in this tag in each record is an operational algorithms listed in this tag in each record is an operational
choice made by the Signer. choice made by the Signer.
ABNF: ABNF:
skipping to change at page 32, line 17 skipping to change at page 32, line 36
should the signature fail to verify. Verifiers MAY wish to track should the signature fail to verify. Verifiers MAY wish to track
testing mode results to assist the signer. testing mode results to assist the signer.
s Any DKIM-Signature header fields using the "i=" tag MUST have the s Any DKIM-Signature header fields using the "i=" tag MUST have the
same domain value on the right-hand side of the "@" in the "i=" same domain value on the right-hand side of the "@" in the "i="
tag and the value of the "d=" tag. That is, the "i=" domain MUST tag and the value of the "d=" tag. That is, the "i=" domain MUST
NOT be a subdomain of "d=". Use of this flag is RECOMMENDED NOT be a subdomain of "d=". Use of this flag is RECOMMENDED
unless subdomaining is required. unless subdomaining is required.
ABNF: ABNF:
key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag
0*( [FWS] ":" [FWS] key-t-tag-flag ) 0*( [FWS] ":" [FWS] key-t-tag-flag )
key-t-tag-flag = "y" / "s" / x-key-t-tag-flag key-t-tag-flag = "y" / "s" / x-key-t-tag-flag
x-key-t-tag-flag = hyphenated-word ; for future extension x-key-t-tag-flag = hyphenated-word ; for future extension
Unrecognized flags MUST be ignored.
3.6.2. DNS Binding 3.6.2. DNS Binding
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. Namespace 3.6.2.1. Namespace
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
skipping to change at page 32, line 48 skipping to change at page 33, line 29
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 whitespace. TXT RRs MUST be unique for a particular intervening whitespace. TXT RRs MUST be unique for a particular
selector name; that is, if there are multiple records in an RRset, selector name; that is, if there are multiple records in an RRset,
the results are undefined. the results are undefined.
TXT RRs are encoded as described in Section 3.6.1 TXT RRs are encoded as described in Section 3.6.1.
3.7. Computing the Message Hashes 3.7. Computing the Message Hashes
Both signing and verifying message signatures start with a step of Both signing and verifying message signatures start with a step of
computing two cryptographic hashes over the message. Signers will computing two cryptographic hashes over the message. Signers will
choose the parameters of the signature as described in Signer Actions choose the parameters of the signature as described in Signer Actions
(Section 5); verifiers will use the parameters specified in the DKIM- (Section 5); verifiers will use the parameters specified in the DKIM-
Signature header field being verified. In the following discussion, Signature header field being verified. In the following discussion,
the names of the tags in the DKIM-Signature header field that either the names of the tags in the DKIM-Signature header field that either
exists (when verifying) or will be created (when signing) are used. exists (when verifying) or will be created (when signing) are used.
skipping to change at page 35, line 33 skipping to change at page 36, line 10
application of the RSA private key using a single "sign()" application of the RSA private key using a single "sign()"
primitive. When using such an API, the last two steps in the primitive. When using such an API, the last two steps in the
algorithm would probably be combined into a single call that would algorithm would probably be combined into a single call that would
perform both the "a-hash-alg" and the "sig-alg". perform both the "a-hash-alg" and the "sig-alg".
3.8. Input Requirements 3.8. Input Requirements
DKIM's design is predicated on valid input. Therefore, signers and DKIM's design is predicated on valid input. Therefore, signers and
verifiers SHOULD take reasonable steps to ensure that the messages verifiers SHOULD take reasonable steps to ensure that the messages
they are processing are valid according to [RFC5322], [RFC2045], and they are processing are valid according to [RFC5322], [RFC2045], and
any other relevant message format standards. See Section 8.15 for any other relevant message format standards. See Section 8.14 and
additional discussion and references. Section 8.15 for additional discussion and references.
3.9. Output Requirements 3.9. Output Requirements
For each signature that verifies successfully or produces a TEMPFAIL For each signature that verifies successfully or produces a TEMPFAIL
result, the output of a DKIM verifier module MUST include the set of: result, the output of a DKIM verifier module MUST include the set of:
o The domain name, taken from the "d=" signature tag; and o The domain name, taken from the "d=" signature tag; and
o The result of the verification attempt for that signature. o The result of the verification attempt for that signature.
skipping to change at page 42, line 43 skipping to change at page 43, line 20
signer MAY include more instances of a header field name in h= than signer MAY include more instances of a header field name in h= than
there are actual corresponding header fields to indicate that there are actual corresponding header fields to indicate that
additional header fields of that name SHOULD NOT be added. additional header fields of that name SHOULD NOT be added.
INFORMATIVE EXAMPLE: INFORMATIVE EXAMPLE:
If the signer wishes to sign two existing Received header fields, If the signer wishes to sign two existing Received header fields,
and the existing header contains: and the existing header contains:
Received: <A> Received: <A>
Received: <B> Received: <B>
Received: <c> Received: <C>
then the resulting DKIM-Signature header field should read: then the resulting DKIM-Signature header field should read:
DKIM-Signature: ... h=Received : Received :... DKIM-Signature: ... h=Received : Received :...
and Received header fields <C> and <B> will be signed in that and Received header fields <C> and <B> will be signed in that
order. order.
Signers should be careful of signing header fields that might have Signers should be careful of signing header fields that might have
additional instances added later in the delivery process, since such additional instances added later in the delivery process, since such
header fields might be inserted after the signed instance or header fields might be inserted after the signed instance or
skipping to change at page 53, line 18 skipping to change at page 53, line 46
difficult. If a selector cannot be found, is that because the difficult. If a selector cannot be found, is that because the
selector has been removed, or was the value changed somehow in selector has been removed, or was the value changed somehow in
transit? If the signature line is missing, is that because it was transit? If the signature line is missing, is that because it was
never there, or was it removed by an overzealous filter? For never there, or was it removed by an overzealous filter? For
diagnostic purposes, the exact reason why the verification fails diagnostic purposes, the exact reason why the verification fails
SHOULD be made available and possibly recorded in the system logs. SHOULD be made available and possibly recorded in the system logs.
If the email cannot be verified, then it SHOULD be treated the same If the email cannot be verified, then it SHOULD be treated the same
as all unverified email regardless of whether or not it looks like it as all unverified email regardless of whether or not it looks like it
was signed. was signed.
See Section 8.14 and Section 8.15 for additional discussion and
references.
7. IANA Considerations 7. IANA Considerations
DKIM has registered namespaces with IANA. In all cases, new values DKIM has registered namespaces with IANA. In all cases, new values
are assigned only for values that have been documented in a published are assigned only for values that have been documented in a published
RFC that has IETF Consensus [RFC5226]. RFC that has IETF Consensus [RFC5226].
This memo updates these registries as described below. Of note is This memo updates these registries as described below. Of note is
the addition of a new "status" column. All registrations into these the addition of a new "status" column. All registrations into these
namespaces MUST include the name being registered, the document in namespaces MUST include the name being registered, the document in
which it was registered or updated, and an indication of its current which it was registered or updated, and an indication of its current
skipping to change at page 56, line 40 skipping to change at page 57, line 13
mechanisms that can be used to produce a digest of message data. mechanisms that can be used to produce a digest of message data.
IANA has established the DKIM Hash Algorithms Registry for such IANA has established the DKIM Hash Algorithms Registry for such
mechanisms. mechanisms.
The updated entries in the registry comprise: The updated entries in the registry comprise:
+--------+-------------------+--------+ +--------+-------------------+--------+
| TYPE | REFERENCE | STATUS | | TYPE | REFERENCE | STATUS |
+--------+-------------------+--------+ +--------+-------------------+--------+
| sha1 | [FIPS-180-2-2002] | active | | sha1 | [FIPS-180-3-2008] | active |
| sha256 | [FIPS-180-2-2002] | active | | sha256 | [FIPS-180-3-2008] | active |
+--------+-------------------+--------+ +--------+-------------------+--------+
DKIM Hash Algorithms Updated Values DKIM Hash Algorithms Updated Values
7.7. DKIM Service Types Registry 7.7. DKIM Service Types Registry
The "s=" <key-s-tag> tag (specified in Section 3.6.1) provides for a The "s=" <key-s-tag> tag (specified in Section 3.6.1) provides for a
list of service types to which this selector may apply. list of service types to which this selector may apply.
IANA has established the DKIM Service Types Registry for service IANA has established the DKIM Service Types Registry for service
skipping to change at page 63, line 49 skipping to change at page 64, line 23
Sections 3.5 and 5.4 for further discussion of this mechanism. Sections 3.5 and 5.4 for further discussion of this mechanism.
Specific validity rules for all known header fields can be gleaned Specific validity rules for all known header fields can be gleaned
from the IANA "Permanent Header Field Registry" and the reference from the IANA "Permanent Header Field Registry" and the reference
documents it identifies. documents it identifies.
9. References 9. References
9.1. Normative References 9.1. Normative References
[FIPS-180-2-2002] [FIPS-180-3-2008]
U.S. Department of Commerce, "Secure Hash Standard", FIPS U.S. Department of Commerce, "Secure Hash Standard", FIPS
PUB 180-2, August 2002. PUB 180-3, October 2008.
[ITU-X660-1997] [ITU-X660-1997]
"Information Technology - ASN.1 encoding rules: "Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", 1997. (DER)", 1997.
[RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", [RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC 1034, November 1987. RFC 1034, November 1987.
skipping to change at page 65, line 46 skipping to change at page 66, line 20
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5451] Kucherawy, M., "Message Header Field for Indicating [RFC5451] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 5451, April 2009. Message Authentication Status", RFC 5451, April 2009.
[RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
Identified Mail (DKIM) Service Overview", RFC 5585, Identified Mail (DKIM) Service Overview", RFC 5585,
July 2009. July 2009.
[RFC5672] Crocker, D., Ed., "RFC 4871 DomainKeys Identified Mail
(DKIM) Signatures -- Update", RFC 5672, August 2009.
[RFC5751] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC5751] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 5751, January 2010. RFC 5751, January 2010.
[RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
"DomainKeys Identified Mail (DKIM) Development, "DomainKeys Identified Mail (DKIM) Development,
Deployment, and Operations", RFC 5863, May 2010. Deployment, and Operations", RFC 5863, May 2010.
Appendix A. Example of Use (INFORMATIVE) Appendix A. Example of Use (INFORMATIVE)
skipping to change at page 73, line 7 skipping to change at page 73, line 20
A common practice among systems that are primarily redistributors of A common practice among systems that are primarily redistributors of
mail is to add a Sender header field to the message, to identify the mail is to add a Sender header field to the message, to identify the
address being used to sign the message. This practice will remove address being used to sign the message. This practice will remove
any preexisting Sender header field as required by [RFC5322]. The any preexisting Sender header field as required by [RFC5322]. The
forwarder applies a new DKIM-Signature header field with the forwarder applies a new DKIM-Signature header field with the
signature, public key, and related information of the forwarder. signature, public key, and related information of the forwarder.
Appendix C. Creating a Public Key (INFORMATIVE) Appendix C. Creating a Public Key (INFORMATIVE)
The default signature is an RSA signed SHA256 digest of the complete The default signature is an RSA signed SHA-256 digest of the complete
email. For ease of explanation, the openssl command is used to email. For ease of explanation, the openssl command is used to
describe the mechanism by which keys and signatures are managed. One describe the mechanism by which keys and signatures are managed. One
way to generate a 1024-bit, unencrypted private key suitable for DKIM way to generate a 1024-bit, unencrypted private key suitable for DKIM
is to use openssl like this: is to use openssl like this:
$ openssl genrsa -out rsa.private 1024 $ openssl genrsa -out rsa.private 1024
For increased security, the "-passin" parameter can also be added to For increased security, the "-passin" parameter can also be added to
encrypt the private key. Use of this parameter will require entering encrypt the private key. Use of this parameter will require entering
a password for several of the following steps. Servers may prefer to a password for several of the following steps. Servers may prefer to
use hardware cryptographic support. use hardware cryptographic support.
skipping to change at page 74, line 32 skipping to change at page 74, line 45
addresses in the domain. This differs from the usage in the original addresses in the domain. This differs from the usage in the original
DKIM specification, where a null "g=" value is not valid for any DKIM specification, where a null "g=" value is not valid for any
address. In particular, the example public key record in Section address. In particular, the example public key record in Section
3.2.3 of [RFC4870] with DKIM. 3.2.3 of [RFC4870] with DKIM.
Although the "g=" tag has been deprecated in this version of the DKIM Although the "g=" tag has been deprecated in this version of the DKIM
specification, signers are advised not to include the "g=" tag in key specification, signers are advised not to include the "g=" tag in key
records because some [RFC4871]-compliant verifiers will be in use for records because some [RFC4871]-compliant verifiers will be in use for
a considerable period to come. a considerable period to come.
Appendix D. MUA Considerations Appendix D. MUA Considerations (INFORMATIVE)
When a DKIM signature is verified, the processing system sometimes When a DKIM signature is verified, the processing system sometimes
makes the result available to the recipient user's MUA. How to makes the result available to the recipient user's MUA. How to
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 SDID, in an attempt to show the user is to have the MUA highlight the SDID, in an attempt to show the user
the identity that is claiming responsibility for the message. An MUA the identity that is claiming responsibility for the message. An MUA
might do this with visual cues such as graphics, or it might include might do this with visual cues such as graphics, or it might include
the address in an alternate view, or it might even rewrite the the address in an alternate view, or it might even rewrite the
original From address using the verified information. Some MUAs original From address using the verified information. Some MUAs
skipping to change at page 75, line 12 skipping to change at page 75, line 25
unsigned header fields in a way that might be construed by the end unsigned header fields in a way that might be construed by the end
user as having been signed. If the message has an l= tag whose value user as having been signed. If the message has an l= tag whose value
does not extend to the end of the message, the MUA might also hide or does not extend to the end of the message, the MUA might also hide or
mark the portion of the message body that was not signed. mark the portion of the message 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. Changes since RFC4871
o Abstract and introduction refined based on accumulated experience.
o Various references updated.
o Several errata resolved:
* 1376 applied
* 1377 applied
* 1378 applied
* 1379 applied
* 1380 applied
* 1381 applied
* 1382 applied
* 1383 discarded (no longer applies)
* 1384 applied
* 1386 applied
* 1461 applied
* 1487 applied
* 1532 applied
* 1596 applied
o Introductory section enumerating relevent architectural documents
added.
o Introductory section briefly discussing the matter of data
integrity added.
o Allow tolerance of some clock drift.
o Drop "g=" tag from key records. The implementation report
indicates that it is not in use.
o Remove errant note about wildcards in the DNS.
o Remove SMTP-specific advice in most places.
o Reduce (non-normative) recommended signature content list, and
rework the text in that section.
o Clarify signature generation algorithm by rewriting its pseudo-
code.
o Numerous terminology subsections added, imported from [RFC5672].
Also began using these terms throughout the document (e.g., SDID,
AUID).
o Sections added that specify input and output requirements. Input
requirements address a security concern raised by the working
group (see also new sections in Security Considerations). Output
requirements are imported from [RFC5672].
o Appendix subsection added discussing compatibility with DomainKeys
([RFC4870]) records.
o Refer to [RFC5451] as an example method of communicating the
results of DKIM verification.
o Remove advice about possible uses of the "l=" signature tag.
o IANA registry update.
o Add two new Security Considerations sections talking about
malformed message attacks.
o Various copy editing.
Appendix F. Acknowledgements
The previous IETF version of DKIM [RFC4871] was edited by: Eric The previous IETF version of DKIM [RFC4871] was edited by: Eric
Allman, Jon Callas, Mark Delany, Miles Libbey, Jim Fenton and Michael Allman, Jon Callas, Mark Delany, Miles Libbey, Jim Fenton and Michael
Thomas. Thomas.
That specification was the result of an extended, collaborative That specification was the result of an extended, collaborative
effort, including participation by: Russ Allbery, Edwin Aoki, Claus effort, including participation by: Russ Allbery, Edwin Aoki, Claus
Assmann, Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve Assmann, Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve
Bellovin, Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis Bellovin, Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis
Dayman, Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark Dayman, Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark
 End of changes. 49 change blocks. 
82 lines changed or deleted 169 lines changed or added

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