ietf-dkim
[Top] [All Lists]
<prev [Date] next>
[Advanced]
 <prev [Thread] next>

[ietf-dkim] draft-ietf-dkim-rfc4871bis-03 submitted

2011-02-16 11:28:39
from [Dave CROCKER] [Permanent Link] 
Folks,

A new version of rfc4871 has just been posted as an I-D.  A diff is attached.

The draft is available at:

   <http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-03>

This version does NOT contain text that resolves two outstanding issues:


Subject: [ietf-dkim] Focusing on 4871bis
Date: Fri, 22 Oct 2010 11:28:10 -0400
From: Barry Leiba <barryleiba(_at_)computer(_dot_)org>

...

2. Advice about wildcards in TXT records.
Proposed change: Add a note in section 6.1.2 warning about the effect
of wildcard TXT records on finding DKIM key records.

3. The issue of multiple occurrences of header fields that may only occur once.
Proposed change: Add text to section 5.3 recommending that verifiers
check that the message complies with specs, and that they not validate
a non-compliant message.  Add a new section 8.14 to the Security
Considerations, explaining the attacks that can be done using this
exposure.
I was not able to determine what the wg rough consensus is, for either of these points, and am unable to formulate a proposal that might move towards resolution.
The best I can suggest is that Barry tell us what text to add when consensus on the relevant changes is reached. 

d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
< draft-ietf-dkim-rfc4871bis-02.txt   draft-ietf-dkim-rfc4871bis-03.txt >
DKIM D. Crocker, Ed. Network Working Group D. Crocker, Ed.
Internet-Draft Brandenburg InternetWorking Internet-Draft Brandenburg InternetWorking
Obsoletes: 4871 (if approved) T. Hansen, Ed. Obsoletes: 4871 (if approved) T. Hansen, Ed.
Intended status: Standards Track AT&T Laboratories Intended status: Standards Track AT&T Laboratories
Expires: April 14, 2011 M. Kucherawy, Ed. Expires: August 20, 2011 M. Kucherawy, Ed.
Cloudmark Cloudmark
October 11, 2010 February 16, 2011
DomainKeys Identified Mail (DKIM) Signatures DomainKeys Identified Mail (DKIM) Signatures
draft-ietf-dkim-rfc4871bis-02 draft-ietf-dkim-rfc4871bis-03
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 43 skipping to change at page 1, line 43
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 April 14, 2011. This Internet-Draft will expire on August 20, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 6 1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 5
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 6 1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 5
1.4. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6
2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 7 2.5. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 6
2.6. Agent or User Identifier (AUID) . . . . . . . . . . . . . 7 2.6. Agent or User Identifier (AUID) . . . . . . . . . . . . . 7
2.7. Identity Assessor . . . . . . . . . . . . . . . . . . . . 8 2.7. Identity Assessor . . . . . . . . . . . . . . . . . . . . 7
2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 8 2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 7
2.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 8 2.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 8
2.10. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 9 2.10. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 8
2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 9 2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 8
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 10 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 12 3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 11
3.3. Signing and Verification Algorithms . . . . . . . . . . . 13 3.3. Signing and Verification Algorithms . . . . . . . . . . . 12
3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15 3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 14
3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 19 3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 18
3.6. Key Management and Representation . . . . . . . . . . . . 28 3.6. Key Management and Representation . . . . . . . . . . . . 27
3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33 3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 32
3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 35 3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 34
3.9. Relationship between SDID and AUID . . . . . . . . . . . . 35 3.9. Relationship between SDID and AUID . . . . . . . . . . . . 34
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 36 4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 35
4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 36 4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 35
4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 38 4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 37
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 39 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 38
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2. Select a Private Key and Corresponding Selector 5.2. Select a Private Key and Corresponding Selector
Information . . . . . . . . . . . . . . . . . . . . . . . 39 Information . . . . . . . . . . . . . . . . . . . . . . . 38
5.3. Normalize the Message to Prevent Transport Conversions . . 40
5.4. Determine the Header Fields to Sign . . . . . . . . . . . 40 5.3. Normalize the Message to Prevent Transport Conversions . . 39
5.5. Recommended Signature Content . . . . . . . . . . . . . . 42 5.4. Determine the Header Fields to Sign . . . . . . . . . . . 39
5.6. Compute the Message Hash and Signature . . . . . . . . . . 44 5.5. Recommended Signature Content . . . . . . . . . . . . . . 41
5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 44 5.6. Compute the Message Hash and Signature . . . . . . . . . . 43
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 45 5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 43
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 44
6.1. Extract Signatures from the Message . . . . . . . . . . . 45 6.1. Extract Signatures from the Message . . . . . . . . . . . 45
6.2. Communicate Verification Results . . . . . . . . . . . . . 51 6.2. Communicate Verification Results . . . . . . . . . . . . . 50
6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 52 6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 51
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 53 7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 52
7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 53 7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 52
7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 54 7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 53
7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 54 7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 53
7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 55 7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 54
7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 56 7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 55
7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 56 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 55
7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 56 7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 55
7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 57 7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 56
8. Security Considerations . . . . . . . . . . . . . . . . . . . 57 8. Security Considerations . . . . . . . . . . . . . . . . . . . 56
8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 57 8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 56
8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 58 8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 57
8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 59 8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 58
8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59 8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 58
8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 60 8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 59
8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 60 8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 59
8.7. Intentionally Malformed Key Records . . . . . . . . . . . 60 8.7. Intentionally Malformed Key Records . . . . . . . . . . . 59
8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 61 8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 60
8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 61 8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 60
8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 61 8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 60
8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 61 8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 60
8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 61 8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 60
8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 62 8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 61
8.14. Attacks Involving Addition of Header Fields . . . . . . . 62 8.14. Attacks Involving Addition of Header Fields . . . . . . . 61
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62
9.1. Normative References . . . . . . . . . . . . . . . . . . . 63 9.1. Normative References . . . . . . . . . . . . . . . . . . . 62
9.2. Informative References . . . . . . . . . . . . . . . . . . 64 9.2. Informative References . . . . . . . . . . . . . . . . . . 63
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 65 Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 64
A.1. The User Composes an Email . . . . . . . . . . . . . . . . 65 A.1. The User Composes an Email . . . . . . . . . . . . . . . . 64
A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 65 A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 64
A.3. The Email Signature is Verified . . . . . . . . . . . . . 66 A.3. The Email Signature is Verified . . . . . . . . . . . . . 65
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 67 Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 66
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 68 B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 67
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 70 B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 69
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 72 Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 71
Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 73 Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 72
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 74 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 72
Appendix F. RFC4871bis Changes . . . . . . . . . . . . . . . . . 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73
F.1. TO DO . . . . . . . . . . . . . . . . . . . . . . . . . . 74
F.2. DONE . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75
1. Introduction 1. Introduction
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 to claim some responsibility for a message by
responsibility for a message by associating the domain with the associating a domain name [RFC1034] with the message [RFC5322]. This
message. This can be an author's organization, an operational relay can be an author's organization, an operational relay or one of their
or one of their agents. Assertion of responsibility is validated agents. Assertion of responsibility is validated through a
through a cryptographic signature and querying the signer's domain cryptographic signature and querying the signer's domain directly to
directly to retrieve the appropriate public key. Message transit retrieve the appropriate public key. Message transit from author to
from author to recipient is through relays that typically make no recipient is through relays that typically make no substantive change
substantive change to the message content and thus preserve the DKIM to the message content and thus preserve the DKIM signature. A
signature. A message can contain multiple signatures, from the same message can contain multiple signatures, from the same or different
or different organizations involved with the message. organizations involved with the message.
The approach taken by DKIM differs from previous approaches to The approach taken by DKIM differs from previous approaches to
message signing (e.g., Secure/Multipurpose Internet Mail Extensions message signing (e.g., Secure/Multipurpose Internet Mail Extensions
(S/MIME) [RFC1847], OpenPGP [RFC4880]) in that: (S/MIME) [RFC1847], OpenPGP [RFC4880]) in that:
o the message signature is written as a message header field so that o the message signature is written as a message header field so that
neither human recipients nor existing MUA (Mail User Agent) neither human recipients nor existing MUA (Mail User Agent)
software is confused by signature-related content appearing in the software is confused by signature-related content appearing in the
message body; message body;
skipping to change at page 6, line 41 skipping to change at page 5, line 41
DKIM differs from traditional hierarchical public-key systems in that DKIM differs from traditional hierarchical public-key systems in that
no Certificate Authority infrastructure is required; the verifier no Certificate Authority infrastructure is required; the verifier
requests the public key from a repository in the domain of the requests the public key from a repository in the domain of the
claimed signer directly rather than from a third party. claimed signer directly rather than from a third party.
The DNS is proposed as the initial mechanism for the public keys. The DNS is proposed as the initial mechanism for the public keys.
Thus, DKIM currently depends on DNS administration and the security Thus, DKIM currently depends on DNS administration and the security
of the DNS system. DKIM is designed to be extensible to other key of the DNS system. DKIM is designed to be extensible to other key
fetching services as they become available. fetching services as they become available.
1.4. Data Integrity
A DKIM signature associates the d= name with the computed hash of
some or all of the message (see Section 3.7) in order to prevent the
re-use of the signature with different messages. Verifying the
signature asserts that the hashed content has not changed since it
was signed, and asserts nothing else about "protecting" the end-to-
end integrity of the message.
2. Terminology and Definitions 2. Terminology and Definitions
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) [RFC4234]. 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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
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
skipping to change at page 8, line 24 skipping to change at page 7, line 34
(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
to a more general message evaluation filtering engine. However, this to a more general message evaluation filtering engine. However, this
additional activity is outside the scope of the DKIM signature additional activity is outside the scope of the DKIM signature
specification. specification.
2.8. Whitespace 2.8. Whitespace
There are three forms of whitespace: There are three forms of whitespace:
o WSP represents simple whitespace, i.e., a space or a tab character o WSP represents simple whitespace, i.e., a space or a tab character
(formal definition in [RFC4234]). (formal definition in [RFC5234]).
o LWSP is linear whitespace, defined as WSP plus CRLF (formal o LWSP is linear whitespace, defined as WSP plus CRLF (formal
definition in [RFC4234]). definition in [RFC5234]).
o FWS is folding whitespace. It allows multiple lines separated by o FWS is folding whitespace. It allows multiple lines separated by
CRLF followed by at least one whitespace, to be joined. CRLF followed by at least one whitespace, to be joined.
The formal ABNF for these are (WSP and LWSP are given for information The formal ABNF for these are (WSP and LWSP are given for information
only): only):
WSP = SP / HTAB WSP = SP / HTAB
LWSP = *(WSP / CRLF WSP) LWSP = *(WSP / CRLF WSP)
FWS = [*WSP CRLF] 1*WSP FWS = [*WSP CRLF] 1*WSP
The definition of FWS is identical to that in [RFC5322] except for The definition of FWS is identical to that in [RFC5322] except for
the exclusion of obs-FWS. the exclusion of obs-FWS.
2.9. Common ABNF Tokens 2.9. Common ABNF Tokens
The following ABNF tokens are used elsewhere in this document: The following ABNF tokens are used elsewhere in this document:
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ]
ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/") ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/")
base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS) base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS)
[ [FWS] "=" [ [FWS] "=" ] ] [ [FWS] "=" [ [FWS] "=" ] ]
hdr-name = field-name
qp-hdr-value = dkim-quoted-printable ; with "|" encoded
2.10. Imported ABNF Tokens 2.10. 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. RFCs should be considered definitive.
The following tokens are imported from [RFC5321]: The following tokens are imported from [RFC5321]:
o "Local-part" (implementation warning: this permits quoted strings) o "Local-part" (implementation warning: this permits quoted strings)
skipping to change at page 9, line 29 skipping to change at page 8, line 39
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)
INFORMATIVE NOTE: Be aware that the ABNF in [RFC2045] does not INFORMATIVE NOTE: Be aware that the ABNF in [RFC2045] does not
obey the rules of [RFC4234] and must be interpreted accordingly, obey the rules of [RFC5234] and must be interpreted accordingly,
particularly as regards case folding. particularly as regards case folding.
Other tokens not defined herein are imported from [RFC4234]. These Other tokens not defined herein are imported from [RFC5234]. These
are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF,
etc. etc.
2.11. DKIM-Quoted-Printable 2.11. DKIM-Quoted-Printable
The DKIM-Quoted-Printable encoding syntax resembles that described in The DKIM-Quoted-Printable encoding syntax resembles that described in
Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded
as an "=" followed by two hexadecimal digits from the alphabet as an "=" followed by two hexadecimal digits from the alphabet
"0123456789ABCDEF" (no 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
skipping to change at page 13, line 37 skipping to change at page 12, line 39
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
omitted tag is treated as having the default value; a tag with an omitted tag is treated as having the default value; a tag with an
empty value explicitly designates the empty string as the value. For empty value explicitly designates the empty string as the value.
example, "g=" does not mean "g=*", even though "g=*" is the default
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. Signers MUST implement and SHOULD sign using rsa-sha256. sha256. Signers MUST implement and SHOULD sign using rsa-sha256.
Verifiers MUST implement rsa-sha256.
INFORMATIVE NOTE: Although sha256 is strongly encouraged, some INFORMATIVE NOTE: Although sha256 is strongly encouraged, some
senders of low-security messages (such as routine newsletters) may senders of low-security messages (such as routine newsletters) may
prefer to use sha1 because of reduced CPU requirements to compute prefer to use sha1 because of reduced CPU requirements to compute
a sha1 hash. In general, sha256 should always be used whenever a sha1 hash. In general, 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
skipping to change at page 20, line 42 skipping to change at page 19, line 42
ABNF: ABNF:
sig-v-tag = %x76 [FWS] "=" [FWS] "1" sig-v-tag = %x76 [FWS] "=" [FWS] "1"
INFORMATIVE NOTE: DKIM-Signature version numbers are expected INFORMATIVE NOTE: DKIM-Signature version numbers are expected
to increase arithmetically as new versions of this to increase arithmetically as new versions of this
specification are released. specification are released.
a= The algorithm used to generate the signature (plain-text; a= The algorithm used to generate the signature (plain-text;
REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256";
signers SHOULD sign using "rsa-sha256". See Section 3.3 for a signers SHOULD sign using "rsa-sha256".
description of algorithms.
ABNF: ABNF:
a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg
sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg
sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h
sig-a-tag-k = "rsa" / x-sig-a-tag-k sig-a-tag-k = "rsa" / x-sig-a-tag-k
sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h
x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) ; for later extension x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT)
x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) ; for later extension ; for later extension
x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT)
; for later extension
b= The signature data (base64; REQUIRED). Whitespace is ignored in b= The signature data (base64; REQUIRED). Whitespace is ignored in
this value and MUST be ignored when reassembling the original this value and MUST be ignored when reassembling the original
signature. In particular, the signing process can safely insert signature. In particular, the signing process can safely insert
FWS in this value in arbitrary places to conform to line-length FWS in this value in arbitrary places to conform to line-length
limits. See Signer Actions Section 5 for how the signature is limits. See Signer Actions (Section 5) for how the signature is
computed. computed.
ABNF: ABNF:
sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data
sig-b-tag-data = ""> sig-b-tag-data = "">
bh= The hash of the canonicalized body part of the message as bh= The hash of the canonicalized body part of the message as
limited by the "l=" tag (base64; REQUIRED). Whitespace is ignored limited by the "l=" tag (base64; REQUIRED). Whitespace is ignored
in this value and MUST be ignored when reassembling the original in this value and MUST be ignored when reassembling the original
signature. In particular, the signing process can safely insert signature. In particular, the signing process can safely insert
skipping to change at page 22, line 14 skipping to change at page 21, line 15
only one algorithm is named, that algorithm is used for the header only one algorithm is named, that algorithm is used for the header
and "simple" is used for the body. For example, "c=relaxed" is and "simple" is used for the body. For example, "c=relaxed" is
treated the same as "c=relaxed/simple". treated the same as "c=relaxed/simple".
ABNF: ABNF:
sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg
["/" sig-c-tag-alg] ["/" sig-c-tag-alg]
sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg
x-sig-c-tag-alg = hyphenated-word ; for later extension x-sig-c-tag-alg = hyphenated-word ; for later extension
d= Specifies the SDID claiming responsibility for an introduction of d= The SDID claiming responsibility for an introduction of a message
a message into the mail stream (plain-text; REQUIRED). Hence, the into the mail stream (plain-text; REQUIRED). Hence, the SDID
SDID value is used to form the query for the public key. The SDID value is used to form the query for the public key. The SDID MUST
MUST correspond to a valid DNS name under which the DKIM key correspond to a valid DNS name under which the DKIM key record is
record is published. The conventions and semantics used by a published. The conventions and semantics used by a signer to
signer to create and use a specific SDID are outside the scope of create and use a specific SDID are outside the scope of the DKIM
the DKIM Signing specification, as is any use of those conventions Signing specification, as is any use of those conventions and
and semantics. When presented with a signature that does not meet semantics. When presented with a signature that does not meet
these requirements, verifiers MUST consider the signature invalid. these requirements, verifiers MUST consider the signature invalid.
Internationalized domain names MUST be encoded as described in Internationalized domain names MUST be encoded as described in
[RFC3490]. [RFC3490].
ABNF: ABNF:
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain) domain-name = sub-domain 1*("." sub-domain)
; from RFC 5321 Domain, but excluding address-literall ; from RFC 5321 Domain, but excluding address-literal
h= Signed header fields (plain-text, but see description; REQUIRED). h= Signed header fields (plain-text, but see description; REQUIRED).
A colon-separated list of header field names that identify the A colon-separated list of header field names that identify the
header fields presented to the signing algorithm. The field MUST header fields presented to the signing algorithm. The field MUST
contain the complete list of header fields in the order presented contain the complete list of header fields in the order presented
to the signing algorithm. The field MAY contain names of header to the signing algorithm. The field MAY contain names of header
fields that do not exist when signed; nonexistent header fields do fields that do not exist when signed; nonexistent header fields do
not contribute to the signature computation (that is, they are not contribute to the signature computation (that is, they are
treated as the null input, including the header field name, the treated as the null input, including the header field name, the
separating colon, the header field value, and any CRLF separating colon, the header field value, and any CRLF
skipping to change at page 23, line 35 skipping to change at page 22, line 35
header fields prevents an attacker from inserting an actual header fields prevents an attacker from inserting an actual
header field with a null value. header field with a null value.
i= The Agent or User Identifier (AUID) on behalf of which the SDID is i= The Agent or User Identifier (AUID) on behalf of which the SDID is
taking responsibility (dkim-quoted-printable; OPTIONAL, default is taking responsibility (dkim-quoted-printable; OPTIONAL, default is
an empty Local-part followed by an "@" followed by the domain from an empty Local-part followed by an "@" followed by the domain from
the "d=" tag). the "d=" tag).
The syntax is a standard email address where the Local-part MAY be The syntax is a standard email address where the Local-part MAY be
omitted. The domain part of the address MUST be the same as, or a omitted. The domain part of the address MUST be the same as, or a
subdomain of the value of, the "d=" tag. subdomain of, the value of the "d=" tag.
Internationalized domain names MUST be converted using the steps Internationalized domain names MUST be converted using the steps
listed in Section 4 of [RFC3490] using the "ToASCII" function. listed in Section 4 of [RFC3490] using the "ToASCII" function.
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
skipping to change at page 24, line 22 skipping to change at page 23, line 22
assessors is outside the scope of the DKIM Signing specification. assessors is outside the scope of the DKIM Signing specification.
The Signer MAY choose to use the same namespace for its AUIDs as The Signer MAY choose to use the same namespace for its AUIDs as
its users' email addresses or MAY choose other means of its users' email addresses or MAY choose other means of
representing its users. However, the signer SHOULD use the same representing its users. However, the signer SHOULD use the same
AUID for each message intended to be evaluated as being within the AUID for each message intended to be evaluated as being within the
same sphere of responsibility, if it wishes to offer receivers the same sphere of responsibility, if it wishes to offer receivers the
option of using the AUID as a stable identifier that is finer option of using the AUID as a stable identifier that is finer
grained than the SDID. grained than 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.
INFORMATIVE DISCUSSION: This specification does not require the INFORMATIVE DISCUSSION: This specification does not require the
value of the "i=" tag to match the identity in any message value of the "i=" tag to match the identity in any message
header fields. This is considered to be a verifier policy header fields. This is considered to be a verifier policy
skipping to change at page 29, line 34 skipping to change at page 28, line 34
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 %x4B %x49 %x4D %x31
g= Granularity of the key (plain-text; OPTIONAL, default is "*").
This value MUST match the Local-part of the "i=" tag of the DKIM-
Signature header field (or its default value of the empty string
if "i=" is not specified), with a single, optional "*" character
matching a sequence of zero or more arbitrary characters
("wildcarding"). An email with a signing address that does not
match the value of this tag constitutes a failed verification.
The intent of this tag is to constrain which signing address can
legitimately use this selector, for example, when delegating a key
to a third party that should only be used for special purposes.
Wildcarding allows matching for addresses such as "user+*",
"*-offer" or "foo*bar". An empty "g=" value never matches any
addresses.
ABNF:
key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart
key-g-tag-lpart = [dot-atom-text] ["*" [dot-atom-text] ]
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. Signers and Verifiers MUST support algorithms that might be used. Signers and Verifiers MUST support
the "sha256" hash algorithm. Verifiers MUST also support the the "sha256" hash algorithm. Verifiers MUST also support the
"sha1" hash algorithm. Unrecognized hash algorithms MUST be "sha1" hash algorithm. Unrecognized hash algorithms MUST be
ignored. ignored.
ABNF: ABNF:
key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg
0*( [FWS] ":" [FWS] key-h-tag-alg ) 0*( [FWS] ":" [FWS] key-h-tag-alg )
skipping to change at page 32, line 34 skipping to change at page 31, line 14
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. Unrecognized flags MUST be ignored.
3.6.1.1. Compatibility Note for DomainKeys
If a v= value is not found at the beginning of the DKIM key record,
the key record MAY be interpreted as for DomainKeys [RFC4870]. The
definition given here is upwardly compatible with what is used for
DomainKeys, with the exception of the "g=" value. In a DomainKeys
key record, an empty "g=" value would be interpreted as being
equivalent to DKIM's "g=*".
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 35, line 9 skipping to change at page 33, line 26
beginning with a "." to avoid confusion with the SMTP end-of-message beginning with a "." to avoid confusion with the SMTP end-of-message
marker, as specified in [RFC5321]). marker, as specified in [RFC5321]).
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
simply a string of octets. DKIM messages MAY be either in plain-text simply a string of octets. DKIM messages MAY be either in plain-text
or in MIME format; no special treatment is afforded to MIME content. or in MIME format; no special treatment is afforded to MIME content.
Message attachments in MIME format MUST be included in the content Message attachments in MIME format MUST be included in the content
that is signed. that is signed.
More formally, the algorithm for the signature is as follows: More formally, the ABNF of the algorithm for the signature is as
body-hash = hash-alg(canon_body) follows:
header-hash = hash-alg(canon_header || DKIM-SIG) body-hash = bh-hash-alg (canon-body, l-param)
signature = sig-alg(header-hash, key) data-hash = a-hash-alg (h-headers, D-SIG, content-hash)
signature = sig-alg (d-domain, selector, data-hash)
where "sig-alg" is the signature algorithm specified by the "a=" tag, where:
"hash-alg" is the hash algorithm specified by the "a=" tag,
"canon_header" and "canon_body" are the canonicalized message header
and body (respectively) as defined in Section 3.4 (excluding the
DKIM-Signature header field), and "DKIM-SIG" is the canonicalized
DKIM-Signature header field sans the signature value itself, but with
"body-hash" included as the "bh=" tag.
INFORMATIVE IMPLEMENTERS' NOTE: Many digital signature APIs body-hash: is the output of a function to hash the Body.
provide both hashing and application of the RSA private key using
a single "sign()" primitive. When using such an API, the last two bh-hash-alg: is the hashing algorithm specified in the "bh"
steps in the algorithm would probably be combined into a single parameter.
call that would perform both the "hash-alg" and the "sig-alg".
canon-body: is a canonicalized representation of the body.
l-param: is the value of the l= length parameter.
data-hash: is the output from hashing the header, the
DOSETA-Signature header, and the Content hash.
a-hash-alg: is the hash algorithm specified by the "a=" tag,
h-headers: is the list of headers to be signed, as specified in
the h= parameter.
D-SIG: is the canonicalized DOSETA-Signature field sans the
signature value itself.
canon-body: is the canonicalized Body as defined in Section 3.4
(excluding the DKIM-Signature field).
signature: is the signature value produced by the signing
algorithm.
sig-alg: is the signature algorithm specified by the "a=" tag,
d-domain: is the domain name specified in the d= parameter.
selector: is the value of the s= selector parameter
NOTE: Many digital signature APIs provide both hashing and
application of the RSA private key using a single "sign()"
primitive. When using such an API, the last two steps in the
algorithm would probably be combined into a single call that would
perform both the "a-hash-alg" and the "sig-alg".
3.8. Signing by Parent Domains 3.8. Signing by Parent Domains
In some circumstances, it is desirable for a domain to apply a In some circumstances, it is desirable for a domain to apply a
signature on behalf of any of its subdomains without the need to signature on behalf of any of its subdomains without the need to
maintain separate selectors (key records) in each subdomain. By maintain separate selectors (key records) in each subdomain. By
default, private keys corresponding to key records can be used to default, private keys corresponding to key records can be used to
sign messages for any subdomain of the domain in which they reside; sign messages for any subdomain of the domain in which they reside;
for example, a key record for the domain example.com can be used to for example, a key record for the domain example.com can be used to
verify messages where the AUID ("i=" tag of the signature) is verify messages where the AUID ("i=" tag of the signature) is
skipping to change at page 36, line 7 skipping to change at page 35, line 7
3.9. Relationship between SDID and AUID 3.9. Relationship between SDID and AUID
DKIM's primary task is to communicate from the Signer to a recipient- DKIM's primary task is to communicate from the Signer to a recipient-
side Identity Assessor a single Signing Domain Identifier (SDID) that side Identity Assessor a single Signing Domain Identifier (SDID) that
refers to a responsible identity. DKIM MAY optionally provide a refers to a responsible identity. DKIM MAY optionally provide a
single responsible Agent or User Identifier (AUID). single responsible Agent or User Identifier (AUID).
Hence, DKIM's mandatory output to a receive-side Identity Assessor is Hence, DKIM's mandatory output to a receive-side Identity Assessor is
a single domain name. Within the scope of its use as DKIM output, a single domain name. Within the scope of its use as DKIM output,
the name hnamas only basic domain name semantics; any possible owner- the name has only basic domain name semantics; any possible owner-
specific semantics are outside the scope of DKIM. That is, within specific semantics are outside the scope of DKIM. That is, within
its role as a DKIM identifier, additional semantics cannot be assumed its role as a DKIM identifier, additional semantics cannot be assumed
by an Identity Assessor. by an Identity Assessor.
A receive-side DKIM verifier MUST communicate the Signing Domain Upon successfully verifying the signature, a receive-side DKIM
Identifier (d=) to a consuming Identity Assessor module and MAY verifier MUST communicate the Signing Domain Identifier (d=) to a
communicate the Agent or User Identifier (i=) if present. consuming Identity Assessor module and MAY communicate the Agent or
User Identifier (i=) if present.
To the extent that a receiver attempts to intuit any structured To the extent that a receiver attempts to intuit any structured
semantics for either of the identifiers, this is a heuristic function semantics for either of the identifiers, this is a heuristic function
that is outside the scope of DKIM's specification and semantics. that is outside the scope of DKIM's specification and semantics.
Hence, it is relegated to a higher-level service, such as a delivery Hence, it is relegated to a higher-level service, such as a delivery
handling filter that integrates a variety of inputs and performs handling filter that integrates a variety of inputs and performs
heuristic analysis of them. heuristic analysis of them.
INFORMATIVE DISCUSSION: This document does not require the value INFORMATIVE DISCUSSION: This document does not require the value
of the SDID or AUID to match an identifier in any other message of the SDID or AUID to match an identifier in any other message
skipping to change at page 40, line 28 skipping to change at page 39, line 28
Some messages, particularly those using 8-bit characters, are subject Some messages, particularly those using 8-bit characters, are subject
to modification during transit, notably conversion to 7-bit form. to modification during transit, notably conversion to 7-bit form.
Such conversions will break DKIM signatures. In order to minimize Such conversions will break DKIM signatures. In order to minimize
the chances of such breakage, signers SHOULD convert the message to a the chances of such breakage, signers SHOULD convert the message to a
suitable MIME content transfer encoding such as quoted-printable or suitable MIME content transfer encoding such as quoted-printable or
base64 as described in [RFC2045] before signing. Such conversion is base64 as described in [RFC2045] before signing. Such conversion is
outside the scope of DKIM; the actual message SHOULD be converted to outside the scope of DKIM; the actual message SHOULD be converted to
7-bit MIME by an MUA or MSA prior to presentation to the DKIM 7-bit MIME by an MUA or MSA prior to presentation to the DKIM
algorithm. algorithm.
Similarly, a message that is not compliant with RFC5322, RFC2045 Similarly, a message that is not compliant with RFC5322, RFC2045 and
correct or interpret such content. See Section 8 of [RFC4409] for RFC2047, can be subject to attempts by intermediaries to correct or
examples of changes that are commonly made. Such "corrections" may interpret such content. See Section 8 of [RFC4409] for examples of
break DKIM signatures or have other undesirable effects. Therefore, changes that are commonly made. Such "corrections" may break DKIM
a verifier SHOULD NOT validate a message that is not conformant. signatures or have other undesirable effects. Therefore, a verifier
SHOULD NOT validate a message that is not compliant with those
specifications.
If the message is submitted to the signer with any local encoding If the message is submitted to the signer with any local encoding
that will be modified before transmission, that modification to that will be modified before transmission, that modification to
canonical [RFC5322] form MUST be done before signing. In particular, canonical [RFC5322] form MUST be done before signing. In particular,
bare CR or LF characters (used by some systems as a local line bare CR or LF characters (used by some systems as a local line
separator convention) MUST be converted to the SMTP-standard CRLF separator convention) MUST be converted to the SMTP-standard CRLF
sequence before the message is signed. Any conversion of this sort sequence before the message is signed. Any conversion of this sort
SHOULD be applied to the message actually sent to the recipient(s), SHOULD be applied to the message actually sent to the recipient(s),
not just to the version presented to the signing algorithm. not just to the version presented to the signing algorithm.
skipping to change at page 48, line 44 skipping to change at page 48, line 5
The public key for a signature is needed to complete the verification The public key for a signature is needed to complete the verification
process. The process of retrieving the public key depends on the process. The process of retrieving the public key depends on the
query type as defined by the "q=" tag in the DKIM-Signature header query type as defined by the "q=" tag in the DKIM-Signature header
field. Obviously, a public key need only be retrieved if the process field. Obviously, a public key need only be retrieved if the process
of extracting the signature information is completely successful. of extracting the signature information is completely successful.
Details of key management and representation are described in Details of key management and representation are described in
Section 3.6. The verifier MUST validate the key record and MUST Section 3.6. The verifier MUST validate the key record and MUST
ignore any public key records that are malformed. ignore any public key records that are malformed.
NOTE: The use of wildcard TXT records in the DNS will produce a
response to a DKIM query that is unlikely to be valid DKIM key
record. This problem applies to many other types of queries, and
client software that processes DNS responses needs to take this
problem into account.
When validating a message, a verifier MUST perform the following When validating a message, a verifier MUST perform the following
steps in a manner that is semantically the same as performing them in steps in a manner that is semantically the same as performing them in
the order indicated (in some cases, the implementation may the order indicated -- in some cases the implementation may
parallelize or reorder these steps, as long as the semantics remain parallelize or reorder these steps, as long as the semantics remain
unchanged): unchanged:
1. Retrieve the public key as described in Section 3.6 using the 1. Retrieve the public key as described in Section 3.6 using the
algorithm in the "q=" tag, the domain from the "d=" tag, and the algorithm in the "q=" tag, the domain from the "d=" tag, and the
selector from the "s=" tag. selector from the "s=" tag.
2. If the query for the public key fails to respond, the verifier 2. If the query for the public key fails to respond, the verifier
MAY defer acceptance of this email and return TEMPFAIL (key MAY defer acceptance of this email and return TEMPFAIL (key
unavailable). If verification is occurring during the incoming unavailable). If verification is occurring during the incoming
SMTP session, this MAY be achieved with a 451/4.7.5 SMTP reply SMTP session, this MAY be achieved with a 451/4.7.5 SMTP reply
code. Alternatively, the verifier MAY store the message in the code. Alternatively, the verifier MAY store the message in the
skipping to change at page 49, line 35 skipping to change at page 48, line 50
remainder of this section means "try the next key record, if any; remainder of this section means "try the next key record, if 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. In particular, the verifier MUST ignore avoid attempted attacks. In particular, the verifier MUST ignore
keys with a version code ("v=" tag) that they do not implement. 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 "h=" tag exists in the public key record and the hash
of the "i=" tag in the message signature header field, the
verifier MUST ignore the key record and return PERMFAIL
(inapplicable key). If the Local-part of the "i=" tag on the
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 (which defaults to "g=*"), otherwise the verifier MUST
ignore the key record and return PERMFAIL (inapplicable key).
Other than this test, verifiers SHOULD NOT treat a message signed
with a key record having a "g=" tag any differently than one
without; in particular, verifiers SHOULD NOT prefer messages that
seem to have an individual signature by virtue of a "g=" tag
versus a domain signature.
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 algorithm implied by the a= tag in the DKIM-Signature header
field is not included in the contents of the "h=" tag, the field is not included in the contents of the "h=" tag, the
verifier MUST ignore the key record and return PERMFAIL verifier MUST ignore the key record and return PERMFAIL
(inappropriate hash algorithm). (inappropriate hash algorithm).
8. If the public key data (the "p=" tag) is empty, then this key has 7. 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 8. 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
PERMFAIL (inappropriate key algorithm). PERMFAIL (inappropriate key algorithm).
6.1.3. Compute the Verification 6.1.3. Compute the Verification
Given a signer and a public key, verifying a signature consists of Given a signer and a public key, verifying a signature consists of
actions semantically equivalent to the following steps. actions semantically equivalent to the following steps.
1. Based on the algorithm defined in the "c=" tag, the body length 1. Based on the algorithm defined in the "c=" tag, the body length
skipping to change at page 61, line 24 skipping to change at page 60, line 24
8.9. Information Leakage 8.9. Information Leakage
An attacker could determine when a particular signature was verified An attacker could determine when a particular signature was verified
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 8.11. Reordered Header Fields
Existing standards allow intermediate MTAs to reorder 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 If a signer signs two or more header fields of the same name, this
can cause spurious verification errors on otherwise legitimate can cause spurious verification errors on otherwise legitimate
messages. In particular, signers that sign any existing DKIM- messages. In particular, signers that sign any existing DKIM-
Signature fields run the risk of having messages incorrectly fail to Signature fields run the risk of having messages incorrectly fail to
skipping to change at page 62, line 51 skipping to change at page 61, line 51
be exploited to fool the user if it is also known that the other be exploited to fool the user if it is also known that the other
From: field is the one checked by arriving message filters. Such is From: field is the one checked by arriving message filters. Such is
the case with DKIM; although the From: field must be signed, a the case with DKIM; although the From: field must be signed, a
malformed message bearing more than one From: field might only have malformed message bearing more than one From: field might only have
the first ("bottom") one signed, in an attempt to show the message the first ("bottom") one signed, in an attempt to show the message
with some "DKIM passed" annotation while also rendering the From: with some "DKIM passed" annotation while also rendering the From:
field that was not authenticated. (This can also be taken as a field that was not authenticated. (This can also be taken as a
demonstration that DKIM is not designed to support author demonstration that DKIM is not designed to support author
validation.) validation.)
A signer wishing to be resistant to this specific attack can include To resist this specific attack the signed header field list can
in the signed header field list an additional instance of each field include an additional reference for each field that was present at
that was present at signing. For example, a proper message with one signing. For example, a proper message with one From: field could be
From: field could be signed using "h=From:From:..." Because of the signed using "h=From:From:..." Due to the way header fields are
way header fields are canonicalized for input to the hash function, canonicalized for input to the hash function, the extra field
this would prevent additional fields from being added, after signing, references will prevent instances of the cited fields from being
as this would render the signature invalid. added after signing, as doing so would render the signature invalid.
The From: field is used above to illustrate this issue, but it is
only one of > several fields that Section 3.6 of [RFC5322] constrains
in this way. In reality any agent that forgives malformations, or is
careless about identifying which parts of a message were
authenticated, is open to exploitation.
9. References 9. References
9.1. Normative References 9.1. Normative References
[FIPS-180-2-2002] [FIPS-180-2-2002]
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-2, August 2002.
[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",
RFC 1034, November 1987.
[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 Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996. RFC 2047, November 1996.
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Extensions (MIME) Part Five: Conformance Criteria and
skipping to change at page 63, line 47 skipping to change at page 63, line 9
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, February 2003.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", "Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003. RFC 3490, March 2003.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, January 2008.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
July 2009. July 2009.
skipping to change at page 68, line 22 skipping to change at page 67, line 22
administrative control. This creates challenges for choosing and administrative control. This creates challenges for choosing and
administering the domain name to use for signing, and for its administering the domain name to use for signing, and for its
relationship to common email identity header fields. relationship to common email identity header fields.
B.1.1. Delegated Business Functions B.1.1. Delegated Business Functions
Some organizations assign specific business functions to discrete Some organizations assign specific business functions to discrete
groups, inside or outside the organization. The goal, then, is to groups, inside or outside the organization. The goal, then, is to
authorize that group to sign some mail, but to constrain what authorize that group to sign some mail, but to constrain what
signatures they can generate. DKIM selectors (the "s=" signature signatures they can generate. DKIM selectors (the "s=" signature
tag) and granularity (the "g=" key tag) facilitate this kind of tag) facilitate this kind of restricted authorization. Examples of
restricted authorization. Examples of these outsourced business these outsourced business functions are legitimate email marketing
functions are legitimate email marketing providers and corporate providers and corporate benefits providers.
benefits providers.
Here, the delegated group needs to be able to send messages that are Here, the delegated group needs to be able to send messages that are
signed, using the email domain of the client company. At the same signed, using the email domain of the client company. At the same
time, the client often is reluctant to register a key for the time, the client often is reluctant to register a key for the
provider that grants the ability to send messages for arbitrary provider that grants the ability to send messages for arbitrary
addresses in the domain. addresses in the domain.
There are multiple ways to administer these usage scenarios. In one There are multiple ways to administer these usage scenarios. In one
case, the client organization provides all of the public query case, the client organization provides all of the public query
service (for example, DNS) administration, and in another it uses DNS service (for example, DNS) administration, and in another it uses DNS
delegation to enable all ongoing administration of the DKIM key delegation to enable all ongoing administration of the DKIM key
record by the delegated group. record by the delegated group.
If the client organization retains responsibility for all of the DNS If the client organization retains responsibility for all of the DNS
administration, the outsourcing company can generate a key pair, administration, the outsourcing company can generate a key pair,
supplying the public key to the client company, which then registers supplying the public key to the client company, which then registers
it in the query service, using a unique selector that authorizes a it in the query service, using a unique selector. The client company
specific From header field Local-part. For example, a client with retains control over the use of the delegated key because it retains
the domain "example.com" could have the selector record specify the ability to revoke the key at any time.
"g=winter-promotions" so that this signature is only valid for mail
with a From address of "winter-promotions(_at_)example(_dot_)com". This would
enable the provider to send messages using that specific address and
have them verify properly. The client company retains control over
the email address because it retains the ability to revoke the key at
any time.
If the client wants the delegated group to do the DNS administration, If the client wants the delegated group to do the DNS administration,
it can have the domain name that is specified with the selector point it can have the domain name that is specified with the selector point
to the provider's DNS server. The provider then creates and to the provider's DNS server. The provider then creates and
maintains all of the DKIM signature information for that selector. maintains all of the DKIM signature information for that selector.
Hence, the client cannot provide constraints on the Local-part of Hence, the client cannot provide constraints on the Local-part of
addresses that get signed, but it can revoke the provider's signing addresses that get signed, but it can revoke the provider's signing
rights by removing the DNS delegation record. rights by removing the DNS delegation record.
B.1.2. PDAs and Similar Devices B.1.2. PDAs and Similar Devices
skipping to change at page 71, line 15 skipping to change at page 70, line 8
This is another application that takes advantage of user-level This is another application that takes advantage of user-level
keying, and domains used for affinity addresses would typically have keying, and domains used for affinity addresses would typically have
a very large number of user-level keys. Alternatively, the affinity a very large number of user-level keys. Alternatively, the affinity
domain could handle outgoing mail, operating a mail submission agent domain could handle outgoing mail, operating a mail submission agent
that authenticates users before accepting and signing messages for that authenticates users before accepting and signing messages for
them. This is of course dependent on the user's service provider not them. This is of course dependent on the user's service provider not
blocking the relevant TCP ports used for mail submission. blocking the relevant TCP ports used for mail submission.
B.2.2. Simple Address Aliasing (.forward) B.2.2. Simple Address Aliasing (.forward)
In some cases, a recipient is allowed to configure an email address In some cases a recipient is allowed to configure an email address to
to cause automatic redirection of email messages from the original cause automatic redirection of email messages from the original
address to another, such as through the use of a Unix .forward file. address to another, such as through the use of a Unix .forward file.
In this case, messages are typically redirected by the mail handling In this case, messages are typically redirected by the mail handling
service of the recipient's domain, without modification, except for service of the recipient's domain, without modification, except for
the addition of a Received header field to the message and a change the addition of a Received header field to the message and a change
in the envelope recipient address. In this case, the recipient at in the envelope recipient address. In this case, the recipient at
the final address' mailbox is likely to be able to verify the the final address' mailbox is likely to be able to verify the
original signature since the signed content has not changed, and DKIM original signature since the signed content has not changed, and DKIM
is able to validate the message signature. is able to validate the message signature.
B.2.3. Mailing Lists and Re-Posters B.2.3. Mailing Lists and Re-Posters
skipping to change at page 73, line 4 skipping to change at page 71, line 39
eVYizyuce3/fGke7aRYw/ADKygMJdW8H/OcCQQDz5OQb4j2QDpPZc0Nc4QlbvMsj eVYizyuce3/fGke7aRYw/ADKygMJdW8H/OcCQQDz5OQb4j2QDpPZc0Nc4QlbvMsj
7p7otWRO5xRa6SzXqqV3+F0VpqvDmshEBkoCydaYwc2o6WQ5EBmExeV8124XAkEA 7p7otWRO5xRa6SzXqqV3+F0VpqvDmshEBkoCydaYwc2o6WQ5EBmExeV8124XAkEA
qZzGsIxVP+sEVRWZmW6KNFSdVUpk3qzK0Tz/WjQMe5z0UunY9Ax9/4PVhp/j61bf qZzGsIxVP+sEVRWZmW6KNFSdVUpk3qzK0Tz/WjQMe5z0UunY9Ax9/4PVhp/j61bf
eAYXunajbBSOLlx4D+TunwJBANkPI5S9iylsbLs6NkaMHV6k5ioHBBmgCak95JGX eAYXunajbBSOLlx4D+TunwJBANkPI5S9iylsbLs6NkaMHV6k5ioHBBmgCak95JGX
GMot/L2x0IYyMLAz6oLWh2hm7zwtb0CgOrPo1ke44hFYnfc= GMot/L2x0IYyMLAz6oLWh2hm7zwtb0CgOrPo1ke44hFYnfc=
-----END RSA PRIVATE KEY----- -----END RSA PRIVATE KEY-----
To extract the public-key component from the private key, use openssl To extract the public-key component from the private key, use openssl
like this: like this:
$ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM $ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM
This results in the file rsa.public containing the key information This results in the file rsa.public containing the key information
similar to this: similar to this:
[-----BEGIN PUBLIC KEY----- -----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM
oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R
tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI
MmPSPDdQPNUYckcQ2QIDAQAB MmPSPDdQPNUYckcQ2QIDAQAB
-----END PUBLIC KEY----- -----END PUBLIC KEY-----
This public-key data (without the BEGIN and END tags) is placed in This public-key data (without the BEGIN and END tags) is placed in
the DNS: the DNS:
brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ" brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ"
"KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt" "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt"
"IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v" "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v"
"/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi" "/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi"
"tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB") "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB")
Appendix D. MUA Considerations Appendix D. MUA Considerations
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
skipping to change at page 74, line 31 skipping to change at page 73, line 19
Longsdale, David Margrave, Justin Mason, David Mayne, Thierry Moreau, Longsdale, David Margrave, Justin Mason, David Mayne, Thierry Moreau,
Steve Murphy, Russell Nelson, Dave Oran, Doug Otis, Shamim Pirzada, Steve Murphy, Russell Nelson, Dave Oran, Doug Otis, Shamim Pirzada,
Juan Altmayer Pizzorno, Sanjay Pol, Blake Ramsdell, Christian Renaud, Juan Altmayer Pizzorno, Sanjay Pol, Blake Ramsdell, Christian Renaud,
Scott Renfro, Neil Rerup, Eric Rescorla, Dave Rossetti, Hector Scott Renfro, Neil Rerup, Eric Rescorla, Dave Rossetti, Hector
Santos, Jim Schaad, the Spamhaus.org team, Malte S. Stretz, Robert Santos, Jim Schaad, the Spamhaus.org team, Malte S. Stretz, Robert
Sanders, Rand Wacker, Sam Weiler, and Dan Wing. Sanders, Rand Wacker, Sam Weiler, and Dan Wing.
The earlier DomainKeys was a primary source from which DKIM was The earlier DomainKeys was a primary source from which DKIM was
derived. Further information about DomainKeys is at [RFC4870]. derived. Further information about DomainKeys is at [RFC4870].
Appendix F. RFC4871bis Changes
F.1. TO DO
o Revise summary Introduction to reflect "authentic labeling" rather
than "message authentication".
o Review interoperability items to consider dropping unused
features.
o Review retention of other parameters, such as l=
o "signatures inside parts shouldn't be processed"?
F.2. DONE
o Incorporate Updates RFC
o Added RFC 5598 reference
o Errata ID: 1376 - Verified - sha value for empty bodies
o Errata ID: 1377 - Verified - no trailing CR-LF
o Errata ID: 1378 - Verified - no default algorithm
o Errata ID: 1379 - Verified - z= ABNF
o Errata ID: 1384 - Verified - clarify relaxed step order
o Errata ID: 1461 - Verified - h= ABNF
o Errata ID: 1487 - Verified - v= ABNF
o Errata ID: 1380 - Held for Document Update - x= fudge factor
o Errata ID: 1381 - Held for Document Update - unknown q= value,
h=/k=/s=/t= value
o Errata ID: 1382 - Held for Document Update - unknown s= values
(dup of 1381)
o Errata ID: 1383 - Held for Document Update - add g= example
o Errata ID: 1386 - Held for Document Update - fix DKIM-Signature
example
o Errata ID: 1532 - Held for Document Update - "v=DKIM1"
o Errata ID: 1596 - Held for Document Update - *value* of the b= tag
o Add Authentication Results RFC 5451 to 6.2
Authors' Addresses Authors' Addresses
D. Crocker (editor) D. Crocker (editor)
Brandenburg InternetWorking Brandenburg InternetWorking
675 Spruce Dr. 675 Spruce Dr.
Sunnyvale Sunnyvale
USA USA
Phone: +1.408.246.8253 Phone: +1.408.246.8253
Email: dcrocker(_at_)bbiw(_dot_)net Email: dcrocker(_at_)bbiw(_dot_)net
skipping to change at page 76, line 14 skipping to change at page 73, line 41
Tony Hansen (editor) Tony Hansen (editor)
AT&T Laboratories AT&T Laboratories
200 Laurel Ave. South 200 Laurel Ave. South
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Email: tony+dkimov(_at_)maillennium(_dot_)att(_dot_)com Email: tony+dkimov(_at_)maillennium(_dot_)att(_dot_)com
M. Kucherawy (editor) M. Kucherawy (editor)
Cloudmark Cloudmark
128 King St., 2nd Floor
San Francisco, CA 94107
USA
Email: msk(_at_)cloudmark(_dot_)com Email: msk(_at_)cloudmark(_dot_)com
 End of changes. 60 change blocks. 
272 lines changed or deleted 229 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html
[More with this subject...]
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date:  Re: [ietf-dkim] Interesting recent statistics, Murray S. Kucherawy
Next by Date:  [ietf-dkim] I-D Action:draft-ietf-dkim-rfc4871bis-03.txt, Internet-Drafts
Previous by Thread:  [ietf-dkim] Interesting recent statistics, Murray S. Kucherawy
Next by Thread:  Re: [ietf-dkim] wildcards, draft-ietf-dkim-rfc4871bis-03 submitted, John Levine
Indexes:  [Date] [Thread] [Top] [All Lists]