rfc4871.txt | draft-ietf-dkim-rfc4871bis-00.txt > | |||
---|---|---|---|---|
Network Working Group E. Allman | DKIM D. Crocker | |||
Request for Comments: 4871 Sendmail, Inc. | Internet-Draft Brandenburg InternetWorking | |||
Obsoletes: 4870 J. Callas | Obsoletes: 4871 (if approved) T. Hansen | |||
Category: Standards Track PGP Corporation | Intended status: Standards Track AT&T Laboratories | |||
M. Delany | Expires: February 16, 2011 M. Kucherawy | |||
M. Libbey | Cloudmark | |||
Yahoo! Inc | August 15, 2010 | |||
J. Fenton | ||||
M. Thomas | ||||
Cisco Systems, Inc. | ||||
May 2007 | ||||
DomainKeys Identified Mail (DKIM) Signatures | DomainKeys Identified Mail (DKIM) Signatures | |||
draft-ietf-dkim-rfc4871bis-00 | ||||
Status of This Memo | Abstract | |||
This document specifies an Internet standards track protocol for the | DomainKeys Identified Mail (DKIM) permits a person, role, or | |||
Internet community, and requests discussion and suggestions for | organization that owns the signing domain to claim some | |||
improvements. Please refer to the current edition of the "Internet | responsibility for a message by associating the domain with the | |||
Official Protocol Standards" (STD 1) for the standardization state | message. This can be an author's organization, an operational relay | |||
and status of this protocol. Distribution of this memo is unlimited. | or one of their agents. DKIM separates the question of the identity | |||
of the signer of the message from the purported author of the | ||||
message. Assertion of responsibility is validated through a | ||||
cryptographic signature and querying the signer's domain directly to | ||||
retrieve the appropriate public key. Message transit from author to | ||||
recipient is through relays that typically make no substantive change | ||||
to the message content and thus preserve the DKIM signature. | ||||
Copyright Notice | Status of this Memo | |||
Copyright (C) The IETF Trust (2007). | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | ||||
Abstract | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at http://datatracker.ietf.org/drafts/current/. | ||||
DomainKeys Identified Mail (DKIM) defines a domain-level | Internet-Drafts are draft documents valid for a maximum of six months | |||
authentication framework for email using public-key cryptography and | and may be updated, replaced, or obsoleted by other documents at any | |||
key server technology to permit verification of the source and | time. It is inappropriate to use Internet-Drafts as reference | |||
contents of messages by either Mail Transfer Agents (MTAs) or Mail | material or to cite them other than as "work in progress." | |||
User Agents (MUAs). The ultimate goal of this framework is to permit | ||||
a signing domain to assert responsibility for a message, thus | This Internet-Draft will expire on February 16, 2011. | |||
protecting message signer identity and the integrity of the messages | ||||
they convey while retaining the functionality of Internet email as it | Copyright Notice | |||
is known today. Protection of email identity may assist in the | ||||
global control of "spam" and "phishing". | Copyright (c) 2010 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | ||||
This document is subject to BCP 78 and the IETF Trust's Legal | ||||
Provisions Relating to IETF Documents | ||||
(http://trustee.ietf.org/license-info) in effect on the date of | ||||
publication of this document. Please review these documents | ||||
carefully, as they describe your rights and restrictions with respect | ||||
to this document. Code Components extracted from this document must | ||||
include Simplified BSD License text as described in Section 4.e of | ||||
the Trust Legal Provisions and are provided without warranty as | ||||
described in the Simplified BSD License. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 5 | 1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 5 | 1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 6 | |||
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 | 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 | |||
2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.4. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 6 | 2.4. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 7 | |||
2.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 7 | 2.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 8 | |||
2.6. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 7 | 2.6. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 8 | |||
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8 | 2.7. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 8 | 2.8. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 10 | 2.9. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 10 | |||
3.3. Signing and Verification Algorithms . . . . . . . . . . . 11 | 2.10. Agent or User Identifier (AUID) . . . . . . . . . . . . . 10 | |||
3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 13 | 2.11. Identity Assessor . . . . . . . . . . . . . . . . . . . . 10 | |||
3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 17 | 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 10 | |||
3.6. Key Management and Representation . . . . . . . . . . . . 25 | 3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 29 | 3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 12 | |||
3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 31 | 3.3. Signing and Verification Algorithms . . . . . . . . . . . 13 | |||
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 32 | 3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15 | |||
4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 32 | 3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 19 | |||
4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 33 | 3.6. Key Management and Representation . . . . . . . . . . . . 28 | |||
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 34 | 3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33 | |||
3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 35 | ||||
3.9. Relationship between SDID and AUID . . . . . . . . . . . . 35 | ||||
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 36 | ||||
4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 36 | ||||
4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 37 | ||||
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
5.2. Select a Private Key and Corresponding Selector | 5.2. Select a Private Key and Corresponding Selector | |||
Information . . . . . . . . . . . . . . . . . . . . . . . 35 | Information . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
5.3. Normalize the Message to Prevent Transport Conversions . . 35 | 5.3. Normalize the Message to Prevent Transport Conversions . . 39 | |||
5.4. Determine the Header Fields to Sign . . . . . . . . . . . 36 | 5.4. Determine the Header Fields to Sign . . . . . . . . . . . 40 | |||
5.5. Recommended Signature Content . . . . . . . . . . . . . . 38 | 5.5. Recommended Signature Content . . . . . . . . . . . . . . 42 | |||
5.6. Compute the Message Hash and Signature . . . . . . . . . . 39 | 5.6. Compute the Message Hash and Signature . . . . . . . . . . 43 | |||
5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 40 | 5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 44 | |||
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 40 | 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 44 | |||
6.1. Extract Signatures from the Message . . . . . . . . . . . 41 | 6.1. Extract Signatures from the Message . . . . . . . . . . . 45 | |||
6.2. Communicate Verification Results . . . . . . . . . . . . . 46 | 6.2. Communicate Verification Results . . . . . . . . . . . . . 51 | |||
6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 47 | 6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 51 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 | |||
7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 48 | 7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 52 | |||
7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 49 | 7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 53 | |||
7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 49 | 7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 53 | |||
7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 50 | 7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 54 | |||
7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 50 | 7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 55 | |||
7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 51 | 7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 55 | |||
7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 51 | 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 55 | |||
7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 52 | 7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 56 | |||
7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 52 | 7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 56 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 52 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 56 | |||
8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 52 | 8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 56 | |||
8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 53 | 8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 57 | |||
8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 54 | 8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 58 | |||
8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 54 | 8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 58 | |||
8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 55 | 8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 59 | |||
8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 55 | 8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 60 | |||
8.7. Intentionally Malformed Key Records . . . . . . . . . . . 56 | 8.7. Intentionally Malformed Key Records . . . . . . . . . . . 60 | |||
8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 56 | 8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 60 | |||
8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 56 | 8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 60 | |||
8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 56 | 8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 60 | |||
8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 56 | 8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 60 | |||
8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 56 | 8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 61 | |||
8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 57 | 8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 61 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 57 | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 61 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 58 | 9.2. Informative References . . . . . . . . . . . . . . . . . . 62 | |||
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 60 | Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 63 | |||
A.1. The user composes an email . . . . . . . . . . . . . . . . 60 | A.1. The User Composes an Email . . . . . . . . . . . . . . . . 64 | |||
A.2. The email is signed . . . . . . . . . . . . . . . . . . . 61 | A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 64 | |||
A.3. The email signature is verified . . . . . . . . . . . . . 61 | A.3. The Email Signature is Verified . . . . . . . . . . . . . 65 | |||
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 62 | Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 66 | |||
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 63 | B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 66 | |||
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 65 | B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 68 | |||
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 67 | Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 70 | |||
Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 68 | Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 71 | |||
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 69 | Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 72 | |||
Appendix F. RFC4871bis Changes . . . . . . . . . . . . . . . . . 73 | ||||
F.1. TO DO . . . . . . . . . . . . . . . . . . . . . . . . . . 73 | ||||
F.2. DONE . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 74 | ||||
1. Introduction | 1. Introduction | |||
DomainKeys Identified Mail (DKIM) defines a mechanism by which email | DomainKeys Identified Mail (DKIM) permits a person, role, or | |||
messages can be cryptographically signed, permitting a signing domain | organization that owns the signing domain to claim some | |||
to claim responsibility for the introduction of a message into the | responsibility for a message by associating the domain with the | |||
mail stream. Message recipients can verify the signature by querying | message. This can be an author's organization, an operational relay | |||
the signer's domain directly to retrieve the appropriate public key, | or one of their agents. Assertion of responsibility is validated | |||
and thereby confirm that the message was attested to by a party in | through a cryptographic signature and querying the signer's domain | |||
possession of the private key for the signing domain. | directly to retrieve the appropriate public key. Message transit | |||
from author to recipient is through relays that typically make no | ||||
substantive change to the message content and thus preserve the DKIM | ||||
signature. A message can contain multiple signatures, from the same | ||||
or different 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 [RFC2440]) in that: | (S/MIME) [RFC1847], OpenPGP [RFC2440]) 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 5, line 42 | skipping to change at page 6, line 43 | |||
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. | |||
2. Terminology and Definitions | 2. Terminology and Definitions | |||
This section defines terms used in the rest of the document. Syntax | This section defines terms used in the rest of the document. | |||
descriptions use the form described in Augmented BNF for Syntax | ||||
Specifications [RFC4234]. | DKIM is designed to operate within the Internet Mail service, as | |||
defined in [RFC5598]. Basic email terminology is taken from that | ||||
specification. | ||||
Syntax descriptions use Augmented BNF (ABNF) [RFC4234]. | ||||
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 6, line 38 | skipping to change at page 7, line 42 | |||
(formal definition in [RFC4234]). | (formal definition in [RFC4234]). | |||
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 [RFC4234]). | |||
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 [RFC2822] except for | The definition of FWS is identical to that in [RFC2822] except for | |||
the exclusion of obs-FWS. | the exclusion of obs-FWS. | |||
2.4. Common ABNF Tokens | 2.4. Common ABNF Tokens | |||
The following ABNF tokens are used elsewhere in this document: | The following ABNF tokens are used elsewhere in this document: | |||
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] | hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] | |||
base64string = 1*(ALPHA / DIGIT / "+" / "/" / [FWS]) | ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/") | |||
[ "=" [FWS] [ "=" [FWS] ] ] | base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS) | |||
[ [FWS] "=" [ [FWS] "=" ] ] | ||||
2.5. Imported ABNF Tokens | 2.5. Imported ABNF Tokens | |||
The following tokens are imported from other RFCs as noted. Those | The following tokens are imported from other RFCs as noted. Those | |||
RFCs should be considered definitive. | RFCs should be considered definitive. | |||
The following tokens are imported from [RFC2821]: | The following tokens are imported from [RFC2821]: | |||
o "Local-part" (implementation warning: this permits quoted strings) | o "Local-part" (implementation warning: this permits quoted strings) | |||
skipping to change at page 7, line 28 | skipping to change at page 8, line 33 | |||
o "field-name" (name of a header field) | o "field-name" (name of a header field) | |||
o "dot-atom-text" (in the Local-part of an email address) | o "dot-atom-text" (in the Local-part of an email address) | |||
The following tokens are imported from [RFC2045]: | The following tokens are imported from [RFC2045]: | |||
o "qp-section" (a single line of quoted-printable-encoded text) | o "qp-section" (a single line of quoted-printable-encoded text) | |||
o "hex-octet" (a quoted-printable encoded octet) | o "hex-octet" (a quoted-printable encoded octet) | |||
INFORMATIVE NOTE: Be aware that the ABNF in RFC 2045 does not obey | INFORMATIVE NOTE: Be aware that the ABNF in [RFC2045] does not | |||
the rules of RFC 4234 and must be interpreted accordingly, | obey the rules of [RFC4234] and must be interpreted accordingly, | |||
particularly as regards case folding. | particularly as regards case folding. | |||
Other tokens not defined herein are imported from [RFC4234]. These | Other tokens not defined herein are imported from [RFC4234]. These | |||
are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, | are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, | |||
etc. | etc. | |||
2.6. DKIM-Quoted-Printable | 2.6. DKIM-Quoted-Printable | |||
The DKIM-Quoted-Printable encoding syntax resembles that described in | The DKIM-Quoted-Printable encoding syntax resembles that described in | |||
Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded | Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded | |||
skipping to change at page 8, line 5 | skipping to change at page 9, line 8 | |||
"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. | |||
ABNF: | ABNF: | |||
dkim-quoted-printable = *(FWS / hex-octet / dkim-safe-char) | ||||
dkim-quoted-printable = | ; hex-octet is from RFC2045 | |||
*(FWS / hex-octet / dkim-safe-char) | dkim-safe-char = %x21-3A / %x3C / %x3E-7E | |||
; hex-octet is from RFC 2045 | ; '!' - ':', '<', '>' - '~' | |||
dkim-safe-char = %x21-3A / %x3C / %x3E-7E | ; Characters not listed as "mail-safe" in | |||
; '!' - ':', '<', '>' - '~' | ; RFC2049 are also not recommended. | |||
; Characters not listed as "mail-safe" in | ||||
; RFC 2049 are also not recommended. | ||||
INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted- | INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted- | |||
Printable as defined in RFC 2045 in several important ways: | Printable as defined in [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. RFC 2045 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 | |||
tags encoded using DKIM-Quoted-Printable to be wrapped as | tags encoded using DKIM-Quoted-Printable to be wrapped as | |||
needed. In particular, RFC 2045 requires that line breaks in | needed. In particular, [RFC2045] requires that line breaks in | |||
the input be represented as physical line breaks; that is not | the input be represented as physical line breaks; that is not | |||
the case here. | the case here. | |||
3. The "soft line break" syntax ("=" as the last non-whitespace | 3. The "soft line break" syntax ("=" as the last non-whitespace | |||
character on the line) does not apply. | character on the line) does not apply. | |||
4. DKIM-Quoted-Printable does not require that encoded lines be | 4. DKIM-Quoted-Printable does not require that encoded lines be | |||
no more than 76 characters long (although there may be other | no more than 76 characters long (although there may be other | |||
requirements depending on the context in which the encoded | requirements depending on the context in which the encoded | |||
text is being used). | text is being used). | |||
2.7. Identity | ||||
A person, role, or organization. In the context of DKIM, examples | ||||
include author, author's organization, an ISP along the handling | ||||
path, an independent trust assessment service, and a mailing list | ||||
operator. | ||||
2.8. Identifier | ||||
A label that refers to an identity. | ||||
2.9. Signing Domain Identifier (SDID) | ||||
A single domain name that is the mandatory payload output of DKIM and | ||||
that refers to the identity claiming responsibility for introduction | ||||
of a message into the mail stream. For DKIM processing, the name has | ||||
only basic domain name semantics; any possible owner-specific | ||||
semantics are outside the scope of DKIM. It is specified in | ||||
Section 3.5. | ||||
2.10. Agent or User Identifier (AUID) | ||||
A single identifier that refers to the agent or user on behalf of | ||||
whom the Signing Domain Identifier (SDID) has taken responsibility. | ||||
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 | ||||
of it. For DKIM processing, the domain name portion of the AUID has | ||||
only basic domain name semantics; any possible owner-specific | ||||
semantics are outside the scope of DKIM. It is specified in | ||||
Section 3.5 . | ||||
2.11. Identity Assessor | ||||
A module that consumes DKIM's mandatory payload, which is the | ||||
responsible Signing Domain Identifier (SDID). The module is | ||||
dedicated to the assessment of the delivered identifier. Other DKIM | ||||
(and non-DKIM) values can also be delivered to this module as well as | ||||
to a more general message evaluation filtering engine. However, this | ||||
additional activity is outside the scope of the DKIM signature | ||||
specification. | ||||
3. Protocol Elements | 3. Protocol Elements | |||
Protocol Elements are conceptual parts of the protocol that are not | Protocol Elements are conceptual parts of the protocol that are not | |||
specific to either signers or verifiers. The protocol descriptions | specific to either signers or verifiers. The protocol descriptions | |||
for signers and verifiers are described in later sections (Signer | for signers and verifiers are described in later sections (Signer | |||
Actions (Section 5) and Verifier Actions (Section 6)). NOTE: This | Actions (Section 5) and Verifier Actions (Section 6)). NOTE: This | |||
section must be read in the context of those sections. | section must be read in the context of those sections. | |||
3.1. Selectors | 3.1. Selectors | |||
skipping to change at page 9, line 27 | skipping to change at page 11, line 27 | |||
mail submission agent for outgoing mail. | mail submission agent for outgoing mail. | |||
Periods are allowed in selectors and are component separators. When | Periods are allowed in selectors and are component separators. When | |||
keys are retrieved from the DNS, periods in selectors define DNS | keys are retrieved from the DNS, periods in selectors define DNS | |||
label boundaries in a manner similar to the conventional use in | label boundaries in a manner similar to the conventional use in | |||
domain names. Selector components might be used to combine dates | domain names. Selector components might be used to combine dates | |||
with locations, for example, "march2005.reykjavik". In a DNS | with locations, for example, "march2005.reykjavik". In a DNS | |||
implementation, this can be used to allow delegation of a portion of | implementation, this can be used to allow delegation of a portion of | |||
the selector namespace. | the selector namespace. | |||
ABNF: | ABNF: | |||
selector = sub-domain *( "." sub-domain ) | ||||
selector = sub-domain *( "." sub-domain ) | ||||
The number of public keys and corresponding selectors for each domain | The number of public keys and corresponding selectors for each domain | |||
is determined by the domain owner. Many domain owners will be | is determined by the domain owner. Many domain owners will be | |||
satisfied with just one selector, whereas administratively | satisfied with just one selector, whereas administratively | |||
distributed organizations may choose to manage disparate selectors | distributed organizations may choose to manage disparate selectors | |||
and key pairs in different regions or on different email servers. | and key pairs in different regions or on different email servers. | |||
Beyond administrative convenience, selectors make it possible to | Beyond administrative convenience, selectors make it possible to | |||
seamlessly replace public keys on a routine basis. If a domain | seamlessly replace public keys on a routine basis. If a domain | |||
wishes to change from using a public key associated with selector | wishes to change from using a public key associated with selector | |||
skipping to change at page 11, line 6 | skipping to change at page 13, line 6 | |||
Unencoded semicolon (";") characters MUST NOT occur in the tag value, | Unencoded semicolon (";") characters MUST NOT occur in the tag value, | |||
since that separates tag-specs. | since that separates tag-specs. | |||
INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" defined | INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" defined | |||
below (as "tag-value") only includes 7-bit characters, an | below (as "tag-value") only includes 7-bit characters, an | |||
implementation that wished to anticipate future standards would be | implementation that wished to anticipate future standards would be | |||
advised not to preclude the use of UTF8-encoded text in tag=value | advised not to preclude the use of UTF8-encoded text in tag=value | |||
lists. | lists. | |||
Formally, the syntax rules are as follows: | Formally, the syntax rules are as follows: | |||
tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] | ||||
tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] | tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] | |||
tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] | tag-name = ALPHA 0*ALNUMPUNC | |||
tag-name = ALPHA 0*ALNUMPUNC | tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ] | |||
tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ] | ; WSP and FWS prohibited at beginning and end | |||
; WSP and FWS prohibited at beginning and end | tval = 1*VALCHAR | |||
tval = 1*VALCHAR | VALCHAR = %x21-3A / %x3C-7E | |||
VALCHAR = %x21-3A / %x3C-7E | ; EXCLAMATION to TILDE except SEMICOLON | |||
; EXCLAMATION to TILDE except SEMICOLON | ALNUMPUNC = ALPHA / DIGIT / "_" | |||
ALNUMPUNC = ALPHA / DIGIT / "_" | ||||
Note that WSP is allowed anywhere around tags. In particular, any | Note that WSP is allowed anywhere around tags. In particular, any | |||
WSP after the "=" and any WSP before the terminating ";" is not part | WSP after the "=" and any WSP before the terminating ";" is not part | |||
of the value; however, WSP inside the value is significant. | of the value; however, WSP inside the value is significant. | |||
Tags MUST be interpreted in a case-sensitive manner. Values MUST be | Tags MUST be interpreted in a case-sensitive manner. Values MUST be | |||
processed as case sensitive unless the specific tag description of | processed as case sensitive unless the specific tag description of | |||
semantics specifies case insensitivity. | semantics specifies case insensitivity. | |||
Tags with duplicate names MUST NOT occur within a single tag-list; if | Tags with duplicate names MUST NOT occur within a single tag-list; if | |||
skipping to change at page 11, line 46 | skipping to change at page 13, line 45 | |||
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. For | |||
example, "g=" does not mean "g=*", even though "g=*" is the default | example, "g=" does not mean "g=*", even though "g=*" is the default | |||
for that tag. | for that tag. | |||
3.3. Signing and Verification Algorithms | 3.3. Signing and Verification Algorithms | |||
DKIM supports multiple digital signature algorithms. Two algorithms | DKIM supports multiple digital signature algorithms. Two algorithms | |||
are defined by this specification at this time: rsa-sha1 and rsa- | are defined by this specification at this time: rsa-sha1 and rsa- | |||
sha256. The rsa-sha256 algorithm is the default if no algorithm is | sha256. Signers MUST implement and SHOULD sign using rsa-sha256. | |||
specified. Verifiers MUST implement both rsa-sha1 and rsa-sha256. | ||||
Signers MUST implement and SHOULD sign using 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 | |||
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-2-2002] 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-2-2002] 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. | |||
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 | |||
skipping to change at page 13, line 19 | skipping to change at page 15, line 12 | |||
See [RFC3766] for further discussion on selecting key sizes. | See [RFC3766] for further discussion on selecting key sizes. | |||
3.3.4. Other Algorithms | 3.3.4. Other Algorithms | |||
Other algorithms MAY be defined in the future. Verifiers MUST ignore | Other algorithms MAY be defined in the future. Verifiers MUST ignore | |||
any signatures using algorithms that they do not implement. | any signatures using algorithms that they do not implement. | |||
3.4. Canonicalization | 3.4. Canonicalization | |||
Empirical evidence demonstrates that some mail servers and relay | Some mail systems modify email in transit, potentially invalidating a | |||
systems modify email in transit, potentially invalidating a | signature. For most signers, mild modification of email is | |||
signature. There are two competing perspectives on such | immaterial to validation of the DKIM domain name's use. For such | |||
modifications. For most signers, mild modification of email is | ||||
immaterial to the authentication status of the email. For such | ||||
signers, a canonicalization algorithm that survives modest in-transit | signers, a canonicalization algorithm that survives modest in-transit | |||
modification is preferred. | modification is preferred. | |||
Other signers demand that any modification of the email, however | Other signers demand that any modification of the email, however | |||
minor, result in a signature verification failure. These signers | minor, result in a signature verification failure. These signers | |||
prefer a canonicalization algorithm that does not tolerate in-transit | prefer a canonicalization algorithm that does not tolerate in-transit | |||
modification of the signed email. | modification of the signed email. | |||
Some signers may be willing to accept modifications to header fields | Some signers may be willing to accept modifications to header fields | |||
that are within the bounds of email standards such as [RFC2822], but | that are within the bounds of email standards such as [RFC2822], but | |||
skipping to change at page 15, line 11 | skipping to change at page 16, line 51 | |||
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 | ||||
"CRLF") is: | ||||
uoq1oCgLlTqpdDX/iUbLy7J1Wic= | ||||
The sha256 value is: | ||||
frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY= | ||||
3.4.4. The "relaxed" Body Canonicalization Algorithm | 3.4.4. The "relaxed" Body Canonicalization Algorithm | |||
The "relaxed" body canonicalization algorithm: | The "relaxed" body canonicalization algorithm MUST apply the | |||
following steps (a) and (b) in order: | ||||
o Ignores all whitespace at the end of lines. Implementations MUST | a. Reduce whitespace: | |||
NOT remove the CRLF at the end of the line. | ||||
o Reduces all sequences of WSP within a line to a single SP | * Ignore all whitespace at the end of lines. Implementations | |||
character. | MUST NOT remove the CRLF at the end of the line. | |||
o Ignores all empty lines at the end of the message body. "Empty | * Reduce all sequences of WSP within a line to a single SP | |||
line" is defined in Section 3.4.3. | character. | |||
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 | ||||
does not end with a CRLF, a CRLF is added. (For email, this is | ||||
only possible when using extensions to SMTP or non-SMTP transport | ||||
mechanisms.) | ||||
The sha1 value (in base64) for an empty body (canonicalized to a null | ||||
input) is: | ||||
2jmj7l5rSw0yVb/vlWAYkK/YBwk= | ||||
The sha256 value is: | ||||
47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= | ||||
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 | |||
skipping to change at page 16, line 43 | skipping to change at page 19, line 6 | |||
3.4.6. Canonicalization Examples (INFORMATIVE) | 3.4.6. Canonicalization Examples (INFORMATIVE) | |||
In the following examples, actual whitespace is used only for | In the following examples, actual whitespace is used only for | |||
clarity. The actual input and output text is designated using | clarity. The actual input and output text is designated using | |||
bracketed descriptors: "<SP>" for a space character, "<HTAB>" for a | bracketed descriptors: "<SP>" for a space character, "<HTAB>" for a | |||
tab character, and "<CRLF>" for a carriage-return/line-feed sequence. | tab character, and "<CRLF>" for a carriage-return/line-feed sequence. | |||
For example, "X <SP> Y" and "X<SP>Y" represent the same three | For example, "X <SP> Y" and "X<SP>Y" represent the same three | |||
characters. | characters. | |||
Example 1: A message reading: | Example 1: A message reading: | |||
A: <SP> X <CRLF> | ||||
A: <SP> X <CRLF> | B <SP> : <SP> Y <HTAB><CRLF> | |||
B <SP> : <SP> Y <HTAB><CRLF> | <HTAB> Z <SP><SP><CRLF> | |||
<HTAB> Z <SP><SP><CRLF> | <CRLF> | |||
<CRLF> | <SP> C <SP><CRLF> | |||
<SP> C <SP><CRLF> | D <SP><HTAB><SP> E <CRLF> | |||
D <SP><HTAB><SP> E <CRLF> | <CRLF> | |||
<CRLF> | <CRLF> | |||
<CRLF> | ||||
when canonicalized using relaxed canonicalization for both header and | when canonicalized using relaxed canonicalization for both header and | |||
body results in a header reading: | body results in a header reading: | |||
a:X <CRLF> | ||||
a:X <CRLF> | b:Y <SP> Z <CRLF> | |||
b:Y <SP> Z <CRLF> | ||||
and a body reading: | and a body reading: | |||
<SP> C <CRLF> | ||||
<SP> C <CRLF> | D <SP> E <CRLF> | |||
D <SP> E <CRLF> | ||||
Example 2: The same message canonicalized using simple | Example 2: The same message canonicalized using simple | |||
canonicalization for both header and body results in a header | canonicalization for both header and body results in a header | |||
reading: | reading: | |||
A: <SP> X <CRLF> | ||||
A: <SP> X <CRLF> | B <SP> : <SP> Y <HTAB><CRLF> | |||
B <SP> : <SP> Y <HTAB><CRLF> | <HTAB> Z <SP><SP><CRLF> | |||
<HTAB> Z <SP><SP><CRLF> | ||||
and a body reading: | and a body reading: | |||
<SP> C <SP><CRLF> | ||||
<SP> C <SP><CRLF> | D <SP><HTAB><SP> E <CRLF> | |||
D <SP><HTAB><SP> E <CRLF> | ||||
Example 3: When processed using relaxed header canonicalization and | Example 3: When processed using relaxed header canonicalization and | |||
simple body canonicalization, the canonicalized version has a header | simple body canonicalization, the canonicalized version has a header | |||
of: | of: | |||
a:X <CRLF> | ||||
a:X <CRLF> | b:Y <SP> Z <CRLF> | |||
b:Y <SP> Z <CRLF> | ||||
and a body reading: | and a body reading: | |||
<SP> C <SP><CRLF> | ||||
<SP> C <SP><CRLF> | D <SP><HTAB><SP> E <CRLF> | |||
D <SP><HTAB><SP> E <CRLF> | ||||
3.5. The DKIM-Signature Header Field | 3.5. The DKIM-Signature Header Field | |||
The signature of the email is stored in the DKIM-Signature header | The signature of the email is stored in the DKIM-Signature header | |||
field. This header field contains all of the signature and key- | field. This header field contains all of the signature and key- | |||
fetching data. The DKIM-Signature value is a tag-list as described | fetching data. The DKIM-Signature value is a tag-list as described | |||
in Section 3.2. | in Section 3.2. | |||
The DKIM-Signature header field SHOULD be treated as though it were a | The DKIM-Signature header field SHOULD be treated as though it were a | |||
trace header field as defined in Section 3.6 of [RFC2822], and hence | trace header field as defined in Section 3.6 of [RFC2822], and hence | |||
skipping to change at page 18, line 26 | skipping to change at page 20, line 28 | |||
The encodings for each field type are listed below. Tags described | The encodings for each field type are listed below. Tags described | |||
as qp-section are encoded as described in Section 6.7 of MIME Part | as qp-section are encoded as described in Section 6.7 of MIME Part | |||
One [RFC2045], with the additional conversion of semicolon characters | One [RFC2045], with the additional conversion of semicolon characters | |||
to "=3B"; intuitively, this is one line of quoted-printable encoded | to "=3B"; intuitively, this is one line of quoted-printable encoded | |||
text. The dkim-quoted-printable syntax is defined in Section 2.6. | text. The dkim-quoted-printable syntax is defined in Section 2.6. | |||
Tags on the DKIM-Signature header field along with their type and | Tags on the DKIM-Signature header field along with their type and | |||
requirement status are shown below. Unrecognized tags MUST be | requirement status are shown below. Unrecognized tags MUST be | |||
ignored. | ignored. | |||
v= Version (MUST be included). This tag defines the version of this | v= Version (MUST be included). This tag defines the version of this | |||
specification that applies to the signature record. It MUST have | specification that applies to the signature record. It MUST have | |||
the value "1". Note that verifiers must do a string comparison | the value "1". Note that verifiers must do a string comparison on | |||
on this value; for example, "1" is not the same as "1.0". | this value; for example, "1" is not the same as "1.0". | |||
ABNF: | ||||
sig-v-tag = %x76 [FWS] "=" [FWS] "1" | ||||
INFORMATIVE NOTE: DKIM-Signature version numbers are expected | ||||
to increase arithmetically as new versions of this | ||||
specification are released. | ||||
a= The algorithm used to generate the signature (plain-text; | ||||
REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; | ||||
signers SHOULD sign using "rsa-sha256". See Section 3.3 for a | ||||
description of algorithms. | ||||
ABNF: | ||||
sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg | ABNF: | |||
sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h | sig-v-tag = %x76 [FWS] "=" [FWS] "1" | |||
sig-a-tag-k = "rsa" / x-sig-a-tag-k | ||||
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-h = ALPHA *(ALPHA / DIGIT) ; for later extension | ||||
b= The signature data (base64; REQUIRED). Whitespace is ignored in | INFORMATIVE NOTE: DKIM-Signature version numbers are expected | |||
this value and MUST be ignored when reassembling the original | to increase arithmetically as new versions of this | |||
signature. In particular, the signing process can safely insert | specification are released. | |||
FWS in this value in arbitrary places to conform to line-length | ||||
limits. See Signer Actions (Section 5) for how the signature is | ||||
computed. | ||||
ABNF: | a= The algorithm used to generate the signature (plain-text; | |||
REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; | ||||
signers SHOULD sign using "rsa-sha256". See Section 3.3 for a | ||||
description of algorithms. | ||||
sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data | ABNF: | |||
sig-b-tag-data = base64string | a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg | |||
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-h = "sha1" / "sha256" / x-sig-a-tag-h | ||||
x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) ; for later extension | ||||
x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) ; for later extension | ||||
bh= The hash of the canonicalized body part of the message as limited | b= The signature data (base64; REQUIRED). Whitespace is ignored in | |||
by the "l=" tag (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 Section 3.7 for how the body hash is computed. | computed. | |||
ABNF: | ABNF: | |||
sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data | ||||
sig-b-tag-data = base64string | ||||
sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data | bh= The hash of the canonicalized body part of the message as | |||
sig-bh-tag-data = base64string | limited by the "l=" tag (base64; REQUIRED). Whitespace is ignored | |||
in this value and MUST be ignored when reassembling the original | ||||
signature. In particular, the signing process can safely insert | ||||
FWS in this value in arbitrary places to conform to line-length | ||||
limits. See Section 3.7 for how the body hash is computed. | ||||
c= Message canonicalization (plain-text; OPTIONAL, default is | ABNF: | |||
"simple/simple"). This tag informs the verifier of the type of | sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data | |||
canonicalization used to prepare the message for signing. It | sig-bh-tag-data = base64string | |||
consists of two names separated by a "slash" (%d47) character, | ||||
corresponding to the header and body canonicalization algorithms | ||||
respectively. These algorithms are described in Section 3.4. If | ||||
only one algorithm is named, that algorithm is used for the | ||||
header and "simple" is used for the body. For example, | ||||
"c=relaxed" is treated the same as "c=relaxed/simple". | ||||
ABNF: | c= Message canonicalization (plain-text; OPTIONAL, default is | |||
"simple/simple"). This tag informs the verifier of the type of | ||||
canonicalization used to prepare the message for signing. It | ||||
consists of two names separated by a "slash" (%d47) character, | ||||
corresponding to the header and body canonicalization algorithms | ||||
respectively. These algorithms are described in Section 3.4. If | ||||
only one algorithm is named, that algorithm is used for the header | ||||
and "simple" is used for the body. For example, "c=relaxed" is | ||||
treated the same as "c=relaxed/simple". | ||||
sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg | ABNF: | |||
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= The domain of the signing entity (plain-text; REQUIRED). This is | ||||
the domain that will be queried for the public key. This domain | ||||
MUST be the same as or a parent domain of the "i=" tag (the | ||||
signing identity, as described below), or it MUST meet the | ||||
requirements for parent domain signing described in Section 3.8. | ||||
When presented with a signature that does not meet these | ||||
requirement, verifiers MUST consider the signature invalid. | ||||
Internationalized domain names MUST be encoded as described in | ||||
[RFC3490]. | ||||
ABNF: | ||||
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name | d= Specifies the SDID claiming responsibility for an introduction of | |||
domain-name = sub-domain 1*("." sub-domain) | a message into the mail stream (plain-text; REQUIRED). Hence, the | |||
; from RFC 2821 Domain, but excluding address-literal | SDID value is used to form the query for the public key. The SDID | |||
MUST correspond to a valid DNS name under which the DKIM key | ||||
record is published. The conventions and semantics used by a | ||||
signer to create and use a specific SDID are outside the scope of | ||||
the DKIM Signing specification, as is any use of those conventions | ||||
and semantics. When presented with a signature that does not meet | ||||
these requirements, verifiers MUST consider the signature invalid. | ||||
h= Signed header fields (plain-text, but see description; REQUIRED). | Internationalized domain names MUST be encoded as described in | |||
A colon-separated list of header field names that identify the | [RFC3490]. | |||
header fields presented to the signing algorithm. The field MUST | ||||
contain the complete list of header fields in the order presented | ||||
to the signing algorithm. The field MAY contain names of header | ||||
fields that do not exist when signed; nonexistent header fields | ||||
do not contribute to the signature computation (that is, they are | ||||
treated as the null input, including the header field name, the | ||||
separating colon, the header field value, and any CRLF | ||||
terminator). The field MUST NOT include the DKIM-Signature | ||||
header field that is being created or verified, but may include | ||||
others. Folding whitespace (FWS) MAY be included on either side | ||||
of the colon separator. Header field names MUST be compared | ||||
against actual header field names in a case-insensitive manner. | ||||
This list MUST NOT be empty. See Section 5.4 for a discussion of | ||||
choosing header fields to sign. | ||||
ABNF: | ABNF: | |||
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name | ||||
domain-name = sub-domain 1*("." sub-domain) ; from | ||||
RFC 5321 Domain, but excluding address-literal | ||||
sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name | h= Signed header fields (plain-text, but see description; REQUIRED). | |||
0*( *FWS ":" *FWS hdr-name ) | A colon-separated list of header field names that identify the | |||
hdr-name = field-name | header fields presented to the signing algorithm. The field MUST | |||
contain the complete list of header fields in the order presented | ||||
to the signing algorithm. The field MAY contain names of header | ||||
fields that do not exist when signed; nonexistent header fields do | ||||
not contribute to the signature computation (that is, they are | ||||
treated as the null input, including the header field name, the | ||||
separating colon, the header field value, and any CRLF | ||||
terminator). The field MUST NOT include the DKIM-Signature header | ||||
field that is being created or verified, but may include others. | ||||
Folding whitespace (FWS) MAY be included on either side of the | ||||
colon separator. Header field names MUST be compared against | ||||
actual header field names in a case-insensitive manner. This list | ||||
MUST NOT be empty. See Section 5.4 for a discussion of choosing | ||||
header fields to sign. | ||||
INFORMATIVE EXPLANATION: By "signing" header fields that do not | ABNF: | |||
actually exist, a signer can prevent insertion of those | sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name | |||
header fields before verification. However, since a signer | 0*( [FWS] ":" [FWS] hdr-name ) | |||
cannot possibly know what header fields might be created in | ||||
the future, and that some MUAs might present header fields | ||||
that are embedded inside a message (e.g., as a message/rfc822 | ||||
content type), the security of this solution is not total. | ||||
INFORMATIVE EXPLANATION: The exclusion of the header field name | INFORMATIVE EXPLANATION: By "signing" header fields that do not | |||
and colon as well as the header field value for non-existent | actually exist, a signer can prevent insertion of those header | |||
header fields prevents an attacker from inserting an actual | fields before verification. However, since a signer cannot | |||
header field with a null value. | possibly know what header fields might be created in the | |||
future, and that some MUAs might present header fields that are | ||||
embedded inside a message (e.g., as a message/rfc822 content | ||||
type), the security of this solution is not total. | ||||
i= Identity of the user or agent (e.g., a mailing list manager) on | INFORMATIVE EXPLANATION: The exclusion of the header field name | |||
behalf of which this message is signed (dkim-quoted-printable; | and colon as well as the header field value for non-existent | |||
OPTIONAL, default is an empty Local-part followed by an "@" | header fields prevents an attacker from inserting an actual | |||
followed by the domain from the "d=" tag). The syntax is a | header field with a null value. | |||
standard email address where the Local-part MAY be omitted. The | ||||
domain part of the address MUST be the same as or a subdomain of | ||||
the value of the "d=" tag. | ||||
Internationalized domain names MUST be converted using the steps | i= The Agent or User Identifier (AUID) on behalf of which the SDID is | |||
listed in Section 4 of [RFC3490] using the "ToASCII" function. | taking responsibility (dkim-quoted-printable; OPTIONAL, default is | |||
an empty Local-part followed by an "@" followed by the domain from | ||||
the "d=" tag). | ||||
ABNF: | 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 | ||||
subdomain of the value of, the "d=" tag. | ||||
sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" domain-name | Internationalized domain names MUST be converted using the steps | |||
listed in Section 4 of [RFC3490] using the "ToASCII" function. | ||||
INFORMATIVE NOTE: The Local-part of the "i=" tag is optional | ABNF: | |||
because in some cases a signer may not be able to establish a | sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] | |||
verified individual identity. In such cases, the signer may | "@" domain-name | |||
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 an individual user name within their domain. It can do so | ||||
by including the domain part but not the Local-part of the | ||||
identity. | ||||
INFORMATIVE DISCUSSION: This document does not require the value | The AUID is specified as having the same syntax as an email | |||
of the "i=" tag to match the identity in any message header | address, but is not required to have the same semantics. Notably, | |||
fields. This is considered to be a verifier policy issue. | the domain name is not required to be registered in the DNS -- so | |||
Constraints between the value of the "i=" tag and other | it might not resolve in a query -- and the Local- part MAY be | |||
identities in other header fields seek to apply basic | drawn from a namespace that does not contain the user's mailbox. | |||
authentication into the semantics of trust associated with a | The details of the structure and semantics for the namespace are | |||
role such as content author. Trust is a broad and complex | determined by the Signer. Any knowledge or use of those details | |||
topic and trust mechanisms are subject to highly creative | by verifiers or assessors is outside the scope of the DKIM Signing | |||
attacks. The real-world efficacy of any but the most basic | specification. The Signer MAY choose to use the same namespace | |||
bindings between the "i=" value and other identities is not | for its AUIDs as its users' email addresses or MAY choose other | |||
well established, nor is its vulnerability to subversion by | means of representing its users. However, the signer SHOULD use | |||
an attacker. Hence reliance on the use of these options | the same AUID for each message intended to be evaluated as being | |||
should be strictly limited. In particular, it is not at all | within the same sphere of responsibility, if it wishes to offer | |||
clear to what extent a typical end-user recipient can rely on | receivers the option of using the AUID as a stable identifier that | |||
any assurances that might be made by successful use of the | is finer grained than the SDID. | |||
"i=" options. | ||||
l= Body length count (plain-text unsigned decimal integer; OPTIONAL, | INFORMATIVE NOTE: The Local-part of the "i=" tag is optional | |||
default is entire body). This tag informs the verifier of the | because, in some cases, a signer may not be able to establish a | |||
number of octets in the body of the email after canonicalization | verified individual identity. In such cases, the signer might | |||
included in the cryptographic hash, starting from 0 immediately | wish to assert that although it is willing to go as far as | |||
following the CRLF preceding the body. This value MUST NOT be | signing for the domain, it is unable or unwilling to commit to | |||
larger than the actual number of octets in the canonicalized | an individual user name within their domain. It can do so by | |||
message body. | including the domain part but not the Local-part of the | |||
identity. | ||||
INFORMATIVE IMPLEMENTATION WARNING: Use of the "l=" tag might | INFORMATIVE DISCUSSION: This specification does not require the | |||
allow display of fraudulent content without appropriate | value of the "i=" tag to match the identity in any message | |||
warning to end users. The "l=" tag is intended for | header fields. This is considered to be a verifier policy | |||
increasing signature robustness when sending to mailing lists | issue. Constraints between the value of the "i=" tag and other | |||
that both modify their content and do not sign their | identities in other header fields seek to apply basic | |||
messages. However, using the "l=" tag enables attacks in | authentication into the semantics of trust associated with a | |||
which an intermediary with malicious intent modifies a | role such as content author. Trust is a broad and complex | |||
message to include content that solely benefits the attacker. | topic and trust mechanisms are subject to highly creative | |||
It is possible for the appended content to completely replace | attacks. The real-world efficacy of any but the most basic | |||
the original content in the end recipient's eyes and to | bindings between the "i=" value and other identities is not | |||
defeat duplicate message detection algorithms. Examples are | well established, nor is its vulnerability to subversion by an | |||
described in Security Considerations (Section 8). To avoid | attacker. Hence reliance on the use of these options should be | |||
this attack, signers should be extremely wary of using this | strictly limited. In particular, it is not at all clear to | |||
tag, and verifiers might wish to ignore the tag or remove | what extent a typical end-user recipient can rely on any | |||
text that appears after the specified content length. | assurances that might be made by successful use of the "i=" | |||
options. | ||||
INFORMATIVE NOTE: The value of the "l=" tag is constrained to 76 | l= Body length count (plain-text unsigned decimal integer; OPTIONAL, | |||
decimal digits. This constraint is not intended to predict | default is entire body). This tag informs the verifier of the | |||
the size of future messages or to require implementations to | number of octets in the body of the email after canonicalization | |||
use an integer representation large enough to represent the | included in the cryptographic hash, starting from 0 immediately | |||
maximum possible value, but is intended to remind the | following the CRLF preceding the body. This value MUST NOT be | |||
implementer to check the length of this and all other tags | larger than the actual number of octets in the canonicalized | |||
during verification and to test for integer overflow when | message body. | |||
decoding the value. Implementers may need to limit the | ||||
actual value expressed to a value smaller than 10^76, e.g., | ||||
to allow a message to fit within the available storage space. | ||||
ABNF: | INFORMATIVE IMPLEMENTATION WARNING: Use of the "l=" tag might | |||
allow display of fraudulent content without appropriate warning | ||||
to end users. The "l=" tag is intended for increasing | ||||
signature robustness when sending to mailing lists that both | ||||
modify their content and do not sign their messages. However, | ||||
using the "l=" tag enables attacks in which an intermediary | ||||
with malicious intent modifies a message to include content | ||||
that solely benefits the attacker. It is possible for the | ||||
appended content to completely replace the original content in | ||||
the end recipient's eyes and to defeat duplicate message | ||||
detection algorithms. Examples are described in Security | ||||
Considerations Section 8. To avoid this attack, signers should | ||||
be extremely wary of using this tag, and verifiers might wish | ||||
to ignore the tag or remove text that appears after the | ||||
specified content length. | ||||
sig-l-tag = %x6c [FWS] "=" [FWS] 1*76DIGIT | INFORMATIVE NOTE: The value of the "l=" tag is constrained to | |||
76 decimal digits. This constraint is not intended to predict | ||||
the size of future messages or to require implementations to | ||||
use an integer representation large enough to represent the | ||||
maximum possible value, but is intended to remind the | ||||
implementer to check the length of this and all other tags | ||||
during verification and to test for integer overflow when | ||||
decoding the value. Implementers may need to limit the actual | ||||
value expressed to a value smaller than 10^76, e.g., to allow a | ||||
message to fit within the available storage space. | ||||
q= A colon-separated list of query methods used to retrieve the | ABNF: | |||
public key (plain-text; OPTIONAL, default is "dns/txt"). Each | sig-l-tag = %x6c [FWS] "=" [FWS] | |||
query method is of the form "type[/options]", where the syntax | 1*76DIGIT | |||
and semantics of the options depend on the type and specified | ||||
options. If there are multiple query mechanisms listed, the | ||||
choice of query mechanism MUST NOT change the interpretation of | ||||
the signature. Implementations MUST use the recognized query | ||||
mechanisms in the order presented. | ||||
Currently, the only valid value is "dns/txt", which defines the DNS | q= A colon-separated list of query methods used to retrieve the | |||
TXT record lookup algorithm described elsewhere in this document. | public key (plain-text; OPTIONAL, default is "dns/txt"). Each | |||
The only option defined for the "dns" query type is "txt", which | query method is of the form "type[/options]", where the syntax and | |||
MUST be included. Verifiers and signers MUST support "dns/txt". | semantics of the options depend on the type and specified options. | |||
If there are multiple query mechanisms listed, the choice of query | ||||
mechanism MUST NOT change the interpretation of the signature. | ||||
Implementations MUST use the recognized query mechanisms in the | ||||
order presented. Unrecognized query mechanisms MUST be ignored. | ||||
ABNF: | Currently, the only valid value is "dns/txt", which defines the | |||
DNS TXT record lookup algorithm described elsewhere in this | ||||
document. The only option defined for the "dns" query type is | ||||
"txt", which MUST be included. Verifiers and signers MUST support | ||||
"dns/txt". | ||||
sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method | ABNF: | |||
*([FWS] ":" [FWS] sig-q-tag-method) | sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method | |||
sig-q-tag-method = "dns/txt" / x-sig-q-tag-type | *([FWS] ":" [FWS] sig-q-tag-method) | |||
sig-q-tag-method = "dns/txt" / x-sig-q-tag-type | ||||
["/" x-sig-q-tag-args] | ["/" x-sig-q-tag-args] | |||
x-sig-q-tag-type = hyphenated-word ; for future extension | x-sig-q-tag-type = hyphenated-word ; for future extension | |||
x-sig-q-tag-args = qp-hdr-value | x-sig-q-tag-args = qp-hdr-value | |||
s= The selector subdividing the namespace for the "d=" (domain) tag | ||||
(plain-text; REQUIRED). | ||||
ABNF: | ||||
sig-s-tag = %x73 [FWS] "=" [FWS] selector | ||||
t= Signature Timestamp (plain-text unsigned decimal integer; | s= The selector subdividing the namespace for the "d=" (domain) tag | |||
RECOMMENDED, default is an unknown creation time). The time that | (plain-text; REQUIRED). | |||
this signature was created. The format is the number of seconds | ||||
since 00:00:00 on January 1, 1970 in the UTC time zone. The | ||||
value is expressed as an unsigned integer in decimal ASCII. This | ||||
value is not constrained to fit into a 31- or 32-bit integer. | ||||
Implementations SHOULD be prepared to handle values up to at | ||||
least 10^12 (until approximately AD 200,000; this fits into 40 | ||||
bits). To avoid denial-of-service attacks, implementations MAY | ||||
consider any value longer than 12 digits to be infinite. Leap | ||||
seconds are not counted. Implementations MAY ignore signatures | ||||
that have a timestamp in the future. | ||||
ABNF: | ABNF: | |||
sig-s-tag = %x73 [FWS] "=" [FWS] selector | ||||
sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT | t= Signature Timestamp (plain-text unsigned decimal integer; | |||
RECOMMENDED, default is an unknown creation time). The time that | ||||
this signature was created. The format is the number of seconds | ||||
since 00:00:00 on January 1, 1970 in the UTC time zone. The value | ||||
is expressed as an unsigned integer in decimal ASCII. This value | ||||
is not constrained to fit into a 31- or 32-bit integer. | ||||
Implementations SHOULD be prepared to handle values up to at least | ||||
10^12 (until approximately AD 200,000; this fits into 40 bits). | ||||
To avoid denial-of-service attacks, implementations MAY consider | ||||
any value longer than 12 digits to be infinite. Leap seconds are | ||||
not counted. Implementations MAY ignore signatures that have a | ||||
timestamp in the future. | ||||
x= Signature Expiration (plain-text unsigned decimal integer; | ABNF: | |||
RECOMMENDED, default is no expiration). The format is the same | sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT | |||
as in the "t=" tag, represented as an absolute date, not as a | ||||
time delta from the signing timestamp. The value is expressed as | ||||
an unsigned integer in decimal ASCII, with the same constraints | ||||
on the value in the "t=" tag. Signatures MAY be considered | ||||
invalid if the verification time at the verifier is past the | ||||
expiration date. The verification time should be the time that | ||||
the message was first received at the administrative domain of | ||||
the verifier if that time is reliably available; otherwise the | ||||
current time should be used. The value of the "x=" tag MUST be | ||||
greater than the value of the "t=" tag if both are present. | ||||
INFORMATIVE NOTE: The "x=" tag is not intended as an anti-replay | x= Signature Expiration (plain-text unsigned decimal integer; | |||
defense. | RECOMMENDED, default is no expiration). The format is the same as | |||
in the "t=" tag, represented as an absolute date, not as a time | ||||
delta from the signing timestamp. The value is expressed as an | ||||
unsigned integer in decimal ASCII, with the same constraints on | ||||
the value in the "t=" tag. Signatures MAY be considered invalid | ||||
if the verification time at the verifier is past the expiration | ||||
date. The verification time should be the time that the message | ||||
was first received at the administrative domain of the verifier if | ||||
that time is reliably available; otherwise the current time should | ||||
be used. The value of the "x=" tag MUST be greater than the value | ||||
of the "t=" tag if both are present. | ||||
ABNF: | INFORMATIVE NOTE: The "x=" tag is not intended as an anti- | |||
replay defense. | ||||
sig-x-tag = %x78 [FWS] "=" [FWS] 1*12DIGIT | INFORMATIVE NOTE: Due to clock drift, the receiver's notion of | |||
when to consider the signature expired may not match exactly | ||||
when the sender is expecting. Receivers MAY add a 'fudge | ||||
factor' to allow for such possible drift. | ||||
z= Copied header fields (dkim-quoted-printable, but see description; | ABNF: | |||
OPTIONAL, default is null). A vertical-bar-separated list of | sig-x-tag = %x78 [FWS] "=" [FWS] | |||
selected header fields present when the message was signed, | 1*12DIGIT | |||
including both the field name and value. It is not required to | ||||
include all header fields present at the time of signing. This | ||||
field need not contain the same header fields listed in the "h=" | ||||
tag. The header field text itself must encode the vertical bar | ||||
("|", %x7C) character (i.e., vertical bars in the "z=" text are | ||||
metacharacters, and any actual vertical bar characters in a | ||||
copied header field must be encoded). Note that all whitespace | ||||
must be encoded, including whitespace between the colon and the | ||||
header field value. After encoding, FWS MAY be added at | ||||
arbitrary locations in order to avoid excessively long lines; | ||||
such whitespace is NOT part of the value of the header field, and | ||||
MUST be removed before decoding. | ||||
The header fields referenced by the "h=" tag refer to the fields in | z= Copied header fields (dkim-quoted-printable, but see description; | |||
the RFC 2822 header of the message, not to any copied fields in | OPTIONAL, default is null). A vertical-bar-separated list of | |||
the "z=" tag. Copied header field values are for diagnostic use. | selected header fields present when the message was signed, | |||
including both the field name and value. It is not required to | ||||
include all header fields present at the time of signing. This | ||||
field need not contain the same header fields listed in the "h=" | ||||
tag. The header field text itself must encode the vertical bar | ||||
("|", %x7C) character (i.e., vertical bars in the "z=" text are | ||||
metacharacters, and any actual vertical bar characters in a copied | ||||
header field must be encoded). Note that all whitespace must be | ||||
encoded, including whitespace between the colon and the header | ||||
field value. After encoding, FWS MAY be added at arbitrary | ||||
locations in order to avoid excessively long lines; such | ||||
whitespace is NOT part of the value of the header field, and MUST | ||||
be removed before decoding. | ||||
Header fields with characters requiring conversion (perhaps from | The header fields referenced by the "h=" tag refer to the fields | |||
legacy MTAs that are not [RFC2822] compliant) SHOULD be converted | in the [RFC2822] header of the message, not to any copied fields | |||
as described in MIME Part Three [RFC2047]. | in the "z=" tag. Copied header field values are for diagnostic | |||
use. | ||||
ABNF: | Header fields with characters requiring conversion (perhaps from | |||
sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy | legacy MTAs that are not [RFC2822] compliant) SHOULD be converted | |||
*( [FWS] "|" sig-z-tag-copy ) | as described in MIME Part Three [RFC2047]. | |||
sig-z-tag-copy = hdr-name ":" qp-hdr-value | ||||
qp-hdr-value = dkim-quoted-printable ; with "|" encoded | ||||
INFORMATIVE EXAMPLE of a signature header field spread across | ABNF: | |||
multiple continuation lines: | sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy | |||
*( "|" [FWS] sig-z-tag-copy ) | ||||
sig-z-tag-copy = hdr-name [FWS] ":" qp-hdr-value | ||||
DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane; | INFORMATIVE EXAMPLE of a signature header field spread across | |||
multiple continuation lines: | ||||
DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane; | ||||
c=simple; q=dns/txt; i=@eng.example.net; | c=simple; q=dns/txt; i=@eng.example.net; | |||
t=1117574938; x=1118006938; | t=1117574938; x=1118006938; | |||
h=from:to:subject:date; | h=from:to:subject:date; | |||
z=From:foo@eng.example.net|To:joe@example.com| | z=From:foo@eng.example.net|To:joe@example.com| | |||
Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700; | Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700; | |||
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; | bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; | |||
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ | b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR | |||
VoG4ZHRNiYzR | ||||
3.6. Key Management and Representation | 3.6. Key Management and Representation | |||
Signature applications require some level of assurance that the | Signature applications require some level of assurance that the | |||
verification public key is associated with the claimed signer. Many | verification public key is associated with the claimed signer. Many | |||
applications achieve this by using public key certificates issued by | applications achieve this by using public key certificates issued by | |||
a trusted third party. However, DKIM can achieve a sufficient level | a trusted third party. However, DKIM can achieve a sufficient level | |||
of security, with significantly enhanced scalability, by simply | of security, with significantly enhanced scalability, by simply | |||
having the verifier query the purported signer's DNS entry (or some | having the verifier query the purported signer's DNS entry (or some | |||
security-equivalent) in order to retrieve the public key. | security-equivalent) in order to retrieve the public key. | |||
DKIM keys can potentially be stored in multiple types of key servers | DKIM keys can potentially be stored in multiple types of key servers | |||
and in multiple formats. The storage and format of keys are | and in multiple formats. The storage and format of keys are | |||
irrelevant to the remainder of the DKIM algorithm. | irrelevant to the remainder of the DKIM algorithm. | |||
Parameters to the key lookup algorithm are the type of the lookup | Parameters to the key lookup algorithm are the type of the lookup | |||
(the "q=" tag), the domain of the signer (the "d=" tag of the DKIM- | (the "q=" tag), the domain of the signer (the "d=" tag of the DKIM- | |||
Signature header field), and the selector (the "s=" tag). | Signature header field), and the selector (the "s=" tag). | |||
public_key = dkim_find_key(q_val, d_val, s_val) | ||||
public_key = dkim_find_key(q_val, d_val, s_val) | ||||
This document defines a single binding, using DNS TXT records to | This document defines a single binding, using DNS TXT records to | |||
distribute the keys. Other bindings may be defined in the future. | distribute the keys. Other bindings may be defined in the future. | |||
3.6.1. Textual Representation | 3.6.1. Textual Representation | |||
It is expected that many key servers will choose to present the keys | It is expected that many key servers will choose to present the keys | |||
in an otherwise unstructured text format (for example, an XML form | in an otherwise unstructured text format (for example, an XML form | |||
would not be considered to be unstructured text for this purpose). | would not be considered to be unstructured text for this purpose). | |||
The following definition MUST be used for any DKIM key represented in | The following definition MUST be used for any DKIM key represented in | |||
an otherwise unstructured textual form. | an otherwise unstructured textual form. | |||
The overall syntax is a tag-list as described in Section 3.2. The | The overall syntax is a tag-list as described in Section 3.2. The | |||
current valid tags are described below. Other tags MAY be present | current valid tags are described below. Other tags MAY be present | |||
and MUST be ignored by any implementation that does not understand | and MUST be ignored by any implementation that does not understand | |||
them. | them. | |||
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: | ||||
key-v-tag = %x76 [FWS] "=" [FWS] "DKIM1" | ||||
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+*" or "*-offer". An empty "g=" value never matches any | ||||
addresses. | ||||
ABNF: | ABNF: | |||
key-v-tag = %x76 [FWS] "=" [FWS] %x44 %x4B %x49 %x4D %x31 | ||||
key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart | g= Granularity of the key (plain-text; OPTIONAL, default is "*"). | |||
key-g-tag-lpart = [dot-atom-text] ["*" [dot-atom-text] ] | 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. | ||||
h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to | ABNF: | |||
allowing all algorithms). A colon-separated list of hash | key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart | |||
algorithms that might be used. Signers and Verifiers MUST | key-g-tag-lpart = [dot-atom-text] ["*" [dot-atom-text] ] | |||
support the "sha256" hash algorithm. Verifiers MUST also support | ||||
the "sha1" hash algorithm. | ||||
ABNF: | h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to | |||
allowing all algorithms). A colon-separated list of hash | ||||
algorithms that might be used. Signers and Verifiers MUST support | ||||
the "sha256" hash algorithm. Verifiers MUST also support the | ||||
"sha1" hash algorithm. Unrecognized hash algorithms MUST be | ||||
ignored. | ||||
key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg | ABNF: | |||
key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg | ||||
0*( [FWS] ":" [FWS] key-h-tag-alg ) | 0*( [FWS] ":" [FWS] key-h-tag-alg ) | |||
key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg | key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg | |||
x-key-h-tag-alg = hyphenated-word ; for future extension | x-key-h-tag-alg = hyphenated-word ; for future extension | |||
k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and | ||||
verifiers MUST support the "rsa" key type. The "rsa" key type | ||||
indicates that an ASN.1 DER-encoded [ITU.X660.1997] RSAPublicKey | ||||
[RFC3447] (see Sections 3.1 and A.1.1) is being used in the "p=" | ||||
tag. (Note: the "p=" tag further encodes the value using the | ||||
base64 algorithm.) | ||||
ABNF: | ||||
key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type | ||||
key-k-tag-type = "rsa" / x-key-k-tag-type | ||||
x-key-k-tag-type = hyphenated-word ; for future extension | ||||
n= Notes that might be of interest to a human (qp-section; OPTIONAL, | k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and | |||
default is empty). No interpretation is made by any program. | verifiers MUST support the "rsa" key type. The "rsa" key type | |||
This tag should be used sparingly in any key server mechanism | indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey | |||
that has space limitations (notably DNS). This is intended for | [RFC3447] (see Sections Section 3.1 and A.1.1) is being used in | |||
use by administrators, not end users. | the "p=" tag. (Note: the "p=" tag further encodes the value using | |||
the base64 algorithm.) Unrecognized key types MUST be ignored. | ||||
ABNF: | ABNF: | |||
key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type | ||||
key-k-tag-type = "rsa" / x-key-k-tag-type | ||||
x-key-k-tag-type = hyphenated-word ; for future extension | ||||
key-n-tag = %x6e [FWS] "=" [FWS] qp-section | n= Notes that might be of interest to a human (qp-section; OPTIONAL, | |||
default is empty). No interpretation is made by any program. | ||||
This tag should be used sparingly in any key server mechanism that | ||||
has space limitations (notably DNS). This is intended for use by | ||||
administrators, not end users. | ||||
p= Public-key data (base64; REQUIRED). An empty value means that | ABNF: | |||
this public key has been revoked. The syntax and semantics of | key-n-tag = %x6e [FWS] "=" [FWS] qp-section | |||
this tag value before being encoded in base64 are defined by the | ||||
"k=" tag. | ||||
INFORMATIVE RATIONALE: If a private key has been compromised | p= Public-key data (base64; REQUIRED). An empty value means that | |||
or otherwise disabled (e.g., an outsourcing contract has been | this public key has been revoked. The syntax and semantics of | |||
terminated), a signer might want to explicitly state that it | this tag value before being encoded in base64 are defined by the | |||
knows about the selector, but all messages using that | "k=" tag. | |||
selector should fail verification. Verifiers should ignore | ||||
any DKIM-Signature header fields with a selector referencing | ||||
a revoked key. | ||||
ABNF: | INFORMATIVE RATIONALE: If a private key has been compromised or | |||
otherwise disabled (e.g., an outsourcing contract has been | ||||
terminated), a signer might want to explicitly state that it | ||||
knows about the selector, but all messages using that selector | ||||
should fail verification. Verifiers should ignore any DKIM- | ||||
Signature header fields with a selector referencing a revoked | ||||
key. | ||||
key-p-tag = %x70 [FWS] "=" [ [FWS] base64string ] | ABNF: | |||
key-p-tag = %x70 [FWS] "=" [ [FWS] base64string] | ||||
INFORMATIVE NOTE: A base64string is permitted to include white | INFORMATIVE NOTE: A base64string is permitted to include white | |||
space (FWS) at arbitrary places; however, any CRLFs must be | space (FWS) at arbitrary places; however, any CRLFs must be | |||
followed by at least one WSP character. Implementors and | followed by at least one WSP character. Implementors and | |||
administrators are cautioned to ensure that selector TXT | administrators are cautioned to ensure that selector TXT | |||
records conform to this specification. | records conform to this specification. | |||
s= Service Type (plain-text; OPTIONAL; default is "*"). A colon- | s= Service Type (plain-text; OPTIONAL; default is "*"). A colon- | |||
separated list of service types to which this record applies. | separated list of service types to which this record applies. | |||
Verifiers for a given service type MUST ignore this record if the | Verifiers for a given service type MUST ignore this record if the | |||
appropriate type is not listed. Currently defined service types | appropriate type is not listed. Unrecognized service types MUST | |||
are as follows: | be ignored. Currently defined service types are as follows: | |||
* matches all service types | * matches all service types | |||
email electronic mail (not necessarily limited to SMTP) | email electronic mail (not necessarily limited to SMTP) | |||
This tag is intended to constrain the use of keys for other | This tag is intended to constrain the use of keys for other | |||
purposes, should use of DKIM be defined by other services in the | purposes, should use of DKIM be defined by other services in the | |||
future. | future. | |||
ABNF: | ABNF: | |||
key-s-tag = %x73 [FWS] "=" [FWS] key-s-tag-type | ||||
0*( [FWS] ":" [FWS] key-s-tag-type ) | ||||
key-s-tag-type = "email" / "*" / x-key-s-tag-type | ||||
x-key-s-tag-type = hyphenated-word ; for future extension | ||||
key-s-tag = %x73 [FWS] "=" [FWS] key-s-tag-type | t= Flags, represented as a colon-separated list of names (plain- | |||
0*( [FWS] ":" [FWS] key-s-tag-type ) | text; OPTIONAL, default is no flags set). Unrecognized flags MUST | |||
key-s-tag-type = "email" / "*" / x-key-s-tag-type | be ignored. The defined flags are as follows: | |||
x-key-s-tag-type = hyphenated-word ; for future extension | ||||
t= Flags, represented as a colon-separated list of names (plain- | y This domain is testing DKIM. Verifiers MUST NOT treat messages | |||
text; OPTIONAL, default is no flags set). The defined flags are | from signers in testing mode differently from unsigned email, even | |||
as follows: | should the signature fail to verify. Verifiers MAY wish to track | |||
testing mode results to assist the signer. | ||||
y This domain is testing DKIM. Verifiers MUST NOT treat | s Any DKIM-Signature header fields using the "i=" tag MUST have the | |||
messages from signers in testing mode differently from | same domain value on the right-hand side of the "@" in the "i=" | |||
unsigned email, even should the signature fail to verify. | tag and the value of the "d=" tag. That is, the "i=" domain MUST | |||
Verifiers MAY wish to track testing mode results to assist | NOT be a subdomain of "d=". Use of this flag is RECOMMENDED | |||
the signer. | unless subdomaining is required. | |||
s Any DKIM-Signature header fields using the "i=" tag MUST have | ABNF: | |||
the same domain value on the right-hand side of the "@" in | key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag | |||
the "i=" tag and the value of the "d=" tag. That is, the | 0*( [FWS] ":" [FWS] key-t-tag-flag ) | |||
"i=" domain MUST NOT be a subdomain of "d=". Use of this | key-t-tag-flag = "y" / "s" / x-key-t-tag-flag | |||
flag is RECOMMENDED unless subdomaining is required. | x-key-t-tag-flag = hyphenated-word ; for future extension | |||
ABNF: | Unrecognized flags MUST be ignored. | |||
key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag | 3.6.1.1. Compatibility Note for DomainKeys | |||
0*( [FWS] ":" [FWS] 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 | ||||
Unrecognized flags MUST be ignored. | 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 | |||
skipping to change at page 29, line 34 | skipping to change at page 33, line 17 | |||
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. | |||
Note that canonicalization (Section 3.4) is only used to prepare the | Note that canonicalization (Section 3.4) is only used to prepare the | |||
email for signing or verifying; it does not affect the transmitted | email for signing or verifying; it does not affect the transmitted | |||
email in any way. | email in any way. | |||
The signer/verifier MUST compute two hashes, one over the body of the | The signer/verifier MUST compute two hashes, one over the body of the | |||
message and one over the selected header fields of the message. | message and one over the selected header fields of the message. | |||
skipping to change at page 30, line 27 | skipping to change at page 34, line 8 | |||
In hash step 2, the signer/verifier MUST pass the following to the | In hash step 2, the signer/verifier MUST pass the following to the | |||
hash algorithm in the indicated order. | hash algorithm in the indicated order. | |||
1. The header fields specified by the "h=" tag, in the order | 1. The header fields specified by the "h=" tag, in the order | |||
specified in that tag, and canonicalized using the header | specified in that tag, and canonicalized using the header | |||
canonicalization algorithm specified in the "c=" tag. Each | canonicalization algorithm specified in the "c=" tag. Each | |||
header field MUST be terminated with a single CRLF. | header field MUST be terminated with a single CRLF. | |||
2. The DKIM-Signature header field that exists (verifying) or will | 2. The DKIM-Signature header field that exists (verifying) or will | |||
be inserted (signing) in the message, with the value of the "b=" | be inserted (signing) in the message, with the value of the "b=" | |||
tag deleted (i.e., treated as the empty string), canonicalized | tag (including all surrounding whitespace) deleted (i.e., treated | |||
using the header canonicalization algorithm specified in the "c=" | as the empty string), canonicalized using the header | |||
tag, and without a trailing CRLF. | canonicalization algorithm specified in the "c=" tag, and without | |||
a trailing CRLF. | ||||
All tags and their values in the DKIM-Signature header field are | All tags and their values in the DKIM-Signature header field are | |||
included in the cryptographic hash with the sole exception of the | included in the cryptographic hash with the sole exception of the | |||
value portion of the "b=" (signature) tag, which MUST be treated as | value portion of the "b=" (signature) tag, which MUST be treated as | |||
the null string. All tags MUST be included even if they might not be | the null string. All tags MUST be included even if they might not be | |||
understood by the verifier. The header field MUST be presented to | understood by the verifier. The header field MUST be presented to | |||
the hash algorithm after the body of the message rather than with the | the hash algorithm after the body of the message rather than with the | |||
rest of the header fields and MUST be canonicalized as specified in | rest of the header fields and MUST be canonicalized as specified in | |||
the "c=" (canonicalization) tag. The DKIM-Signature header field | the "c=" (canonicalization) tag. The DKIM-Signature header field | |||
MUST NOT be included in its own h= tag, although other DKIM-Signature | MUST NOT be included in its own h= tag, although other DKIM-Signature | |||
skipping to change at page 31, line 10 | skipping to change at page 34, line 41 | |||
marker, as specified in [RFC2821]). | marker, as specified in [RFC2821]). | |||
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 algorithm for the signature is as follows: | |||
body-hash = hash-alg(canon_body) | body-hash = hash-alg(canon_body) | |||
header-hash = hash-alg(canon_header || DKIM-SIG) | header-hash = hash-alg(canon_header || DKIM-SIG) | |||
signature = sig-alg(header-hash, key) | signature = sig-alg(header-hash, key) | |||
where "sig-alg" is the signature algorithm specified by the "a=" tag, | where "sig-alg" is the signature algorithm specified by the "a=" tag, | |||
"hash-alg" is the hash algorithm specified by the "a=" tag, | "hash-alg" is the hash algorithm specified by the "a=" tag, | |||
"canon_header" and "canon_body" are the canonicalized message header | "canon_header" and "canon_body" are the canonicalized message header | |||
and body (respectively) as defined in Section 3.4 (excluding the | 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), and "DKIM-SIG" is the canonicalized | |||
DKIM-Signature header field sans the signature value itself, but with | DKIM-Signature header field sans the signature value itself, but with | |||
"body-hash" included as the "bh=" tag. | "body-hash" included as the "bh=" tag. | |||
INFORMATIVE IMPLEMENTERS' NOTE: Many digital signature APIs | INFORMATIVE IMPLEMENTERS' NOTE: Many digital signature APIs | |||
skipping to change at page 31, line 35 | skipping to change at page 35, line 18 | |||
steps in the algorithm would probably be combined into a single | steps in the algorithm would probably be combined into a single | |||
call that would perform both the "hash-alg" and the "sig-alg". | call that would perform both the "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; | |||
e.g., a key record for the domain example.com can be used to verify | for example, a key record for the domain example.com can be used to | |||
messages where the signing identity ("i=" tag of the signature) is | verify messages where the AUID ("i=" tag of the signature) is | |||
sub.example.com, or even sub1.sub2.example.com. In order to limit | sub.example.com, or even sub1.sub2.example.com. In order to limit | |||
the capability of such keys when this is not intended, the "s" flag | the capability of such keys when this is not intended, the "s" flag | |||
may be set in the "t=" tag of the key record to constrain the | MAY be set in the "t=" tag of the key record, to constrain the | |||
validity of the record to exactly the domain of the signing identity. | validity of the domain of the AUID. If the referenced key record | |||
If the referenced key record contains the "s" flag as part of the | contains the "s" flag as part of the "t=" tag, the domain of the AUID | |||
"t=" tag, the domain of the signing identity ("i=" flag) MUST be the | ("i=" flag) MUST be the same as that of the SDID (d=) domain. If | |||
same as that of the d= domain. If this flag is absent, the domain of | this flag is absent, the domain of the AUID MUST be the same as, or a | |||
the signing identity MUST be the same as, or a subdomain of, the d= | subdomain of, the SDID. | |||
domain. Key records that are not intended for use with subdomains | ||||
SHOULD specify the "s" flag in the "t=" tag. | 3.9. Relationship between SDID and AUID | |||
DKIM's primary task is to communicate from the Signer to a recipient- | ||||
side Identity Assessor a single Signing Domain Identifier (SDID) that | ||||
refers to a responsible identity. DKIM MAY optionally provide a | ||||
single responsible Agent or User Identifier (AUID). | ||||
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, | ||||
the name has only basic domain name semantics; any possible owner- | ||||
specific semantics are outside the scope of DKIM. That is, within | ||||
its role as a DKIM identifier, additional semantics cannot be assumed | ||||
by an Identity Assessor. | ||||
A receive-side DKIM verifier MUST communicate the Signing Domain | ||||
Identifier (d=) to a 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 | ||||
semantics for either of the identifiers, this is a heuristic function | ||||
that is outside the scope of DKIM's specification and semantics. | ||||
Hence, it is relegated to a higher-level service, such as a delivery | ||||
handling filter that integrates a variety of inputs and performs | ||||
heuristic analysis of them. | ||||
INFORMATIVE DISCUSSION: This document does not require the value | ||||
of the SDID or AUID to match the identifier in any other message | ||||
header field. This requirement is, instead, an assessor policy | ||||
issue. The purpose of such a linkage would be to authenticate the | ||||
value in that other header field. This, in turn, is the basis for | ||||
applying a trust assessment based on the identifier value. Trust | ||||
is a broad and complex topic and trust mechanisms are subject to | ||||
highly creative attacks. The real-world efficacy of any but the | ||||
most basic bindings between the SDID or AUID and other identities | ||||
is not well established, nor is its vulnerability to subversion by | ||||
an attacker. Hence, reliance on the use of such bindings should | ||||
be strictly limited. In particular, it is not at all clear to | ||||
what extent a typical end-user recipient can rely on any | ||||
assurances that might be made by successful use of the SDID or | ||||
AUID. | ||||
4. Semantics of Multiple Signatures | 4. Semantics of Multiple Signatures | |||
4.1. Example Scenarios | 4.1. Example Scenarios | |||
There are many reasons why a message might have multiple signatures. | There are many reasons why a message might have multiple signatures. | |||
For example, a given signer might sign multiple times, perhaps with | For example, a given signer might sign multiple times, perhaps with | |||
different hashing or signing algorithms during a transition phase. | different hashing or signing algorithms during a transition phase. | |||
INFORMATIVE EXAMPLE: Suppose SHA-256 is in the future found to be | INFORMATIVE EXAMPLE: Suppose SHA-256 is in the future found to be | |||
skipping to change at page 35, line 32 | skipping to change at page 39, line 50 | |||
key should be retained for a reasonable validation interval before | key should be retained for a reasonable validation interval before | |||
being removed from the key server. | being removed from the key server. | |||
5.3. Normalize the Message to Prevent Transport Conversions | 5.3. Normalize the Message to Prevent Transport Conversions | |||
Some messages, particularly those using 8-bit characters, are subject | Some messages, particularly those using 8-bit characters, are subject | |||
to modification during transit, notably conversion to 7-bit form. | to modification during transit, notably conversion to 7-bit form. | |||
Such conversions will break DKIM signatures. In order to minimize | Such conversions will break DKIM signatures. In order to minimize | |||
the chances of such breakage, signers SHOULD convert the message to a | the chances of such breakage, signers SHOULD convert the message to a | |||
suitable MIME content transfer encoding such as quoted-printable or | suitable MIME content transfer encoding such as quoted-printable or | |||
base64 as described in MIME Part One [RFC2045] before signing. Such | base64 as described in [RFC2045] before signing. Such conversion is | |||
conversion is outside the scope of DKIM; the actual message SHOULD be | outside the scope of DKIM; the actual message SHOULD be converted to | |||
converted to 7-bit MIME by an MUA or MSA prior to presentation to the | 7-bit MIME by an MUA or MSA prior to presentation to the DKIM | |||
DKIM algorithm. | algorithm. | |||
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 [RFC2822] form MUST be done before signing. In particular, | canonical [RFC2822] 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 37, line 20 | skipping to change at page 41, line 33 | |||
DKIM-Signature header field, and MUST sign such header fields in | DKIM-Signature header field, and MUST sign such header fields in | |||
order from the bottom of the header field block to the top. The | order from the bottom of the header field block to the top. The | |||
signer MAY include more instances of a header field name in h= than | signer MAY include more instances of a header field name in h= than | |||
there are actual corresponding header fields to indicate that | there are actual corresponding header fields to indicate that | |||
additional header fields of that name SHOULD NOT be added. | additional header fields of that name SHOULD NOT be added. | |||
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 | |||
otherwise reordered. Trace header fields (such as Received) and | otherwise reordered. Trace header fields (such as Received) and | |||
Resent-* blocks are the only fields prohibited by [RFC2822] from | Resent-* blocks are the only fields prohibited by [RFC2822] from | |||
being reordered. In particular, since DKIM-Signature header fields | being reordered. In particular, since DKIM-Signature header fields | |||
may be reordered by some intermediate MTAs, signing existing DKIM- | may be reordered by some intermediate MTAs, signing existing DKIM- | |||
skipping to change at page 46, line 43 | skipping to change at page 51, line 12 | |||
correctly formed, this will appear in the postlude and will not be | correctly formed, this will appear in the postlude and will not be | |||
displayed to the end user. | displayed to the end user. | |||
6.2. Communicate Verification Results | 6.2. Communicate Verification Results | |||
Verifiers wishing to communicate the results of verification to other | Verifiers wishing to communicate the results of verification to other | |||
parts of the mail system may do so in whatever manner they see fit. | parts of the mail system may do so in whatever manner they see fit. | |||
For example, implementations might choose to add an email header | For example, implementations might choose to add an email header | |||
field to the message before passing it on. Any such header field | field to the message before passing it on. Any such header field | |||
SHOULD be inserted before any existing DKIM-Signature or preexisting | SHOULD be inserted before any existing DKIM-Signature or preexisting | |||
authentication status header fields in the header field block. | authentication status header fields in the header field block. The | |||
Authentication-Results: header ([RFC5451]) MAY be used for this | ||||
purpose. | ||||
INFORMATIVE ADVICE to MUA filter writers: Patterns intended to | INFORMATIVE ADVICE to MUA filter writers: Patterns intended to | |||
search for results header fields to visibly mark authenticated | search for results header fields to visibly mark authenticated | |||
mail for end users should verify that such header field was added | mail for end users should verify that such header field was added | |||
by the appropriate verifying domain and that the verified identity | by the appropriate verifying domain and that the verified identity | |||
matches the author identity that will be displayed by the MUA. In | matches the author identity that will be displayed by the MUA. In | |||
particular, MUA filters should not be influenced by bogus results | particular, MUA filters should not be influenced by bogus results | |||
header fields added by attackers. To circumvent this attack, | header fields added by attackers. To circumvent this attack, | |||
verifiers may wish to delete existing results header fields after | verifiers may wish to delete existing results header fields after | |||
verification and before adding a new header field. | verification and before adding a new header field. | |||
6.3. Interpret Results/Apply Local Policy | 6.3. Interpret Results/Apply Local Policy | |||
It is beyond the scope of this specification to describe what actions | It is beyond the scope of this specification to describe what actions | |||
a verifier system should make, but an authenticated email presents an | an Identity Assessor can make, but mail carrying a validated SDID | |||
opportunity to a receiving system that unauthenticated email cannot. | presents an opportunity to an Identity Assessor that unauthenticated | |||
Specifically, an authenticated email creates a predictable identifier | email does not. Specifically, an authenticated email creates a | |||
by which other decisions can reliably be managed, such as trust and | predictable identifier by which other decisions can reliably be | |||
reputation. Conversely, unauthenticated email lacks a reliable | managed, such as trust and reputation. Conversely, unauthenticated | |||
identifier that can be used to assign trust and reputation. It is | email lacks a reliable identifier that can be used to assign trust | |||
reasonable to treat unauthenticated email as lacking any trust and | and reputation. It is reasonable to treat unauthenticated email as | |||
having no positive reputation. | lacking any trust and having no positive reputation. | |||
In general, verifiers SHOULD NOT reject messages solely on the basis | In general, verifiers SHOULD NOT reject messages solely on the basis | |||
of a lack of signature or an unverifiable signature; such rejection | of a lack of signature or an unverifiable signature; such rejection | |||
would cause severe interoperability problems. However, if the | would cause severe interoperability problems. However, if the | |||
verifier does opt to reject such messages (for example, when | verifier does opt to reject such messages (for example, when | |||
communicating with a peer who, by prior agreement, agrees to only | communicating with a peer who, by prior agreement, agrees to only | |||
send signed messages), and the verifier runs synchronously with the | send signed messages), and the verifier runs synchronously with the | |||
SMTP session and a signature is missing or does not verify, the MTA | SMTP session and a signature is missing or does not verify, the MTA | |||
SHOULD use a 550/5.7.x reply code. | SHOULD use a 550/5.7.x reply code. | |||
If it is not possible to fetch the public key, perhaps because the | If it is not possible to fetch the public key, perhaps because the | |||
key server is not available, a temporary failure message MAY be | key server is not available, a temporary failure message MAY be | |||
generated using a 451/4.7.5 reply code, such as: | generated using a 451/4.7.5 reply code, such as: | |||
451 4.7.5 Unable to verify signature - key server unavailable | ||||
451 4.7.5 Unable to verify signature - key server unavailable | ||||
Temporary failures such as inability to access the key server or | Temporary failures such as inability to access the key server or | |||
other external service are the only conditions that SHOULD use a 4xx | other external service are the only conditions that SHOULD use a 4xx | |||
SMTP reply code. In particular, cryptographic signature verification | SMTP reply code. In particular, cryptographic signature verification | |||
failures MUST NOT return 4xx SMTP replies. | failures MUST NOT return 4xx SMTP replies. | |||
Once the signature has been verified, that information MUST be | Once the signature has been verified, that information MUST be | |||
conveyed to higher-level systems (such as explicit allow/whitelists | conveyed to the Identity Assessor (such as an explicit allow/ | |||
and reputation systems) and/or to the end user. If the message is | whitelist and reputation system) and/or to the end user. If the SDID | |||
signed on behalf of any address other than that in the From: header | is not the same as the address in the From: header field, the mail | |||
field, the mail system SHOULD take pains to ensure that the actual | system SHOULD take pains to ensure that the actual SDID is clear to | |||
signing identity is clear to the reader. | the reader. | |||
The verifier MAY treat unsigned header fields with extreme | The verifier MAY treat unsigned header fields with extreme | |||
skepticism, including marking them as untrusted or even deleting them | skepticism, including marking them as untrusted or even deleting them | |||
before display to the end user. | before display to the end user. | |||
While the symptoms of a failed verification are obvious -- the | While the symptoms of a failed verification are obvious -- the | |||
signature doesn't verify -- establishing the exact cause can be more | signature doesn't verify -- establishing the exact cause can be more | |||
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 | |||
skipping to change at page 48, line 30 | skipping to change at page 52, line 44 | |||
IANA. In all cases, new values are assigned only for values that | IANA. In all cases, new values are assigned only for values that | |||
have been documented in a published RFC that has IETF Consensus | have been documented in a published RFC that has IETF Consensus | |||
[RFC2434]. | [RFC2434]. | |||
7.1. DKIM-Signature Tag Specifications | 7.1. DKIM-Signature Tag Specifications | |||
A DKIM-Signature provides for a list of tag specifications. IANA has | A DKIM-Signature provides for a list of tag specifications. IANA has | |||
established the DKIM-Signature Tag Specification Registry for tag | established the DKIM-Signature Tag Specification Registry for tag | |||
specifications that can be used in DKIM-Signature fields. | specifications that can be used in DKIM-Signature fields. | |||
The initial entries in the registry comprise: | The initial entries in the registry comprise: | |||
+------+-----------------+ | +------+-----------------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | | |||
+------+-----------------+ | +------+-----------------+ | |||
| v | (this document) | | | v | (this document) | | |||
| a | (this document) | | | a | (this document) | | |||
| b | (this document) | | | b | (this document) | | |||
| bh | (this document) | | | bh | (this document) | | |||
| c | (this document) | | | c | (this document) | | |||
| d | (this document) | | | d | (this document) | | |||
| h | (this document) | | | h | (this document) | | |||
| i | (this document) | | | i | (this document) | | |||
| l | (this document) | | | l | (this document) | | |||
| q | (this document) | | | q | (this document) | | |||
| s | (this document) | | | s | (this document) | | |||
| t | (this document) | | | t | (this document) | | |||
| x | (this document) | | | x | (this document) | | |||
| z | (this document) | | | z | (this document) | | |||
+------+-----------------+ | +------+-----------------+ | |||
DKIM-Signature Tag Specification Registry Initial Values | Table 1: DKIM-Signature Tag Specification Registry Initial | |||
Values | ||||
7.2. DKIM-Signature Query Method Registry | 7.2. DKIM-Signature Query Method Registry | |||
The "q=" tag-spec (specified in Section 3.5) provides for a list of | The "q=" tag-spec (specified in Section 3.5) provides for a list of | |||
query methods. | query methods. | |||
IANA has established the DKIM-Signature Query Method Registry for | IANA has established the DKIM-Signature Query Method Registry for | |||
mechanisms that can be used to retrieve the key that will permit | mechanisms that can be used to retrieve the key that will permit | |||
validation processing of a message signed using DKIM. | validation processing of a message signed using DKIM. | |||
The initial entry in the registry comprises: | The initial entry in the registry comprises: | |||
+------+--------+-----------------+ | +------+--------+-----------------+ | |||
| TYPE | OPTION | REFERENCE | | | TYPE | OPTION | REFERENCE | | |||
+------+--------+-----------------+ | +------+--------+-----------------+ | |||
| dns | txt | (this document) | | | dns | txt | (this document) | | |||
+------+--------+-----------------+ | +------+--------+-----------------+ | |||
DKIM-Signature Query Method Registry Initial Values | DKIM-Signature Query Method Registry Initial Values | |||
7.3. DKIM-Signature Canonicalization Registry | 7.3. DKIM-Signature Canonicalization Registry | |||
The "c=" tag-spec (specified in Section 3.5) provides for a specifier | The "c=" tag-spec (specified in Section 3.5) provides for a specifier | |||
for canonicalization algorithms for the header and body of the | for canonicalization algorithms for the header and body of the | |||
message. | message. | |||
IANA has established the DKIM-Signature Canonicalization Algorithm | IANA has established the DKIM-Signature Canonicalization Algorithm | |||
Registry for algorithms for converting a message into a canonical | Registry for algorithms for converting a message into a canonical | |||
form before signing or verifying using DKIM. | form before signing or verifying using DKIM. | |||
The initial entries in the header registry comprise: | The initial entries in the body registry comprise: | |||
+---------+-----------------+ | ||||
| TYPE | REFERENCE | | ||||
+---------+-----------------+ | ||||
| simple | (this document) | | ||||
| relaxed | (this document) | | ||||
+---------+-----------------+ | ||||
DKIM-Signature Header Canonicalization Algorithm Registry | ||||
Initial Values | ||||
The initial entries in the body registry comprise: | ||||
+---------+-----------------+ | +---------+-----------------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | | |||
+---------+-----------------+ | +---------+-----------------+ | |||
| simple | (this document) | | | simple | (this document) | | |||
| relaxed | (this document) | | | relaxed | (this document) | | |||
+---------+-----------------+ | +---------+-----------------+ | |||
DKIM-Signature Body Canonicalization Algorithm Registry | DKIM-Signature Body Canonicalization Algorithm Registry | |||
Initial Values | Initial Values | |||
7.4. _domainkey DNS TXT Record Tag Specifications | 7.4. _domainkey DNS TXT Record Tag Specifications | |||
A _domainkey DNS TXT record provides for a list of tag | A _domainkey DNS TXT record provides for a list of tag | |||
specifications. IANA has established the DKIM _domainkey DNS TXT Tag | specifications. IANA has established the DKIM _domainkey DNS TXT Tag | |||
Specification Registry for tag specifications that can be used in DNS | Specification Registry for tag specifications that can be used in DNS | |||
TXT Records. | TXT Records. | |||
The initial entries in the registry comprise: | The initial entries in the registry comprise: | |||
+------+-----------------+ | +------+-----------------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | | |||
+------+-----------------+ | +------+-----------------+ | |||
| v | (this document) | | | v | (this document) | | |||
| g | (this document) | | | g | (this document) | | |||
| h | (this document) | | | h | (this document) | | |||
| k | (this document) | | | k | (this document) | | |||
| n | (this document) | | | n | (this document) | | |||
| p | (this document) | | | p | (this document) | | |||
| s | (this document) | | | s | (this document) | | |||
| t | (this document) | | | t | (this document) | | |||
+------+-----------------+ | +------+-----------------+ | |||
DKIM _domainkey DNS TXT Record Tag Specification Registry | DKIM _domainkey DNS TXT Record Tag Specification Registry | |||
Initial Values | Initial Values | |||
The initial entries in the body registry comprise: | ||||
+---------+-----------------+ | ||||
| TYPE | REFERENCE | | ||||
+---------+-----------------+ | ||||
| simple | (this document) | | ||||
| relaxed | (this document) | | ||||
+---------+-----------------+ | ||||
DKIM-Signature Body Canonicalization Algorithm Registry | ||||
Initial Values | ||||
7.5. DKIM Key Type Registry | 7.5. DKIM Key Type Registry | |||
The "k=" <key-k-tag> (specified in Section 3.6.1) and the "a=" <sig- | The "k=" <key-k-tag> (specified in Section 3.6.1) and the "a=" <sig- | |||
a-tag-k> (specified in Section 3.5) tags provide for a list of | a-tag-k> (specified in Section 3.5) tags provide for a list of | |||
mechanisms that can be used to decode a DKIM signature. | mechanisms that can be used to decode a DKIM signature. | |||
IANA has established the DKIM Key Type Registry for such mechanisms. | IANA has established the DKIM Key Type Registry for such mechanisms. | |||
The initial entry in the registry comprises: | The initial entry in the registry comprises: | |||
+------+-----------+ | +------+-----------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | | |||
+------+-----------+ | +------+-----------+ | |||
| rsa | [RFC3447] | | | rsa | [RFC3447] | | |||
+------+-----------+ | +------+-----------+ | |||
DKIM Key Type Initial Values | DKIM Key Type Initial Values | |||
7.6. DKIM Hash Algorithms Registry | 7.6. DKIM Hash Algorithms Registry | |||
The "h=" <key-h-tag> (specified in Section 3.6.1) and the "a=" <sig- | The "h=" <key-h-tag> (specified in Section 3.6.1) and the "a=" <sig- | |||
a-tag-h> (specified in Section 3.5) tags provide for a list of | a-tag-h> (specified in Section 3.5) tags provide for a list of | |||
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 initial entries in the registry comprise: | The initial entries in the registry comprise: | |||
+--------+-------------------+ | +--------+-------------------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | | |||
+--------+-------------------+ | +--------+-------------------+ | |||
| sha1 | [FIPS.180-2.2002] | | | sha1 | [FIPS-180-2-2002] | | |||
| sha256 | [FIPS.180-2.2002] | | | sha256 | [FIPS-180-2-2002] | | |||
+--------+-------------------+ | +--------+-------------------+ | |||
DKIM Hash Algorithms Initial Values | DKIM Hash Algorithms Initial 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 | |||
types. | types. | |||
The initial entries in the registry comprise: | The initial entries in the registry comprise: | |||
+-------+-----------------+ | +-------+-----------------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | | |||
+-------+-----------------+ | +-------+-----------------+ | |||
| email | (this document) | | | email | (this document) | | |||
| * | (this document) | | | * | (this document) | | |||
+-------+-----------------+ | +-------+-----------------+ | |||
DKIM Service Types Registry Initial Values | DKIM Service Types Registry Initial Values | |||
7.8. DKIM Selector Flags Registry | 7.8. DKIM Selector Flags Registry | |||
The "t=" <key-t-tag> tag (specified in Section 3.6.1) provides for a | The "t=" <key-t-tag> tag (specified in Section 3.6.1) provides for a | |||
list of flags to modify interpretation of the selector. | list of flags to modify interpretation of the selector. | |||
IANA has established the DKIM Selector Flags Registry for additional | IANA has established the DKIM Selector Flags Registry for additional | |||
flags. | flags. | |||
The initial entries in the registry comprise: | The initial entries in the registry comprise: | |||
+------+-----------------+ | +------+-----------------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | | |||
+------+-----------------+ | +------+-----------------+ | |||
| y | (this document) | | | y | (this document) | | |||
| s | (this document) | | | s | (this document) | | |||
+------+-----------------+ | +------+-----------------+ | |||
DKIM Selector Flags Registry Initial Values | DKIM Selector Flags Registry Initial Values | |||
7.9. DKIM-Signature Header Field | 7.9. DKIM-Signature Header Field | |||
IANA has added DKIM-Signature to the "Permanent Message Header | IANA has added DKIM-Signature to the "Permanent Message Header | |||
Fields" registry (see [RFC3864]) for the "mail" protocol, using this | Fields" registry (see [RFC3864]) for the "mail" protocol, using this | |||
document as the reference. | document as the reference. | |||
skipping to change at page 53, line 8 | skipping to change at page 57, line 18 | |||
section (including the trailing "--CRLF" portion), then it is | section (including the trailing "--CRLF" portion), then it is | |||
possible for an attacker to intercept a properly signed multipart | possible for an attacker to intercept a properly signed multipart | |||
message and add a new body part. Depending on the details of the | message and add a new body part. Depending on the details of the | |||
MIME type and the implementation of the verifying MTA and the | MIME type and the implementation of the verifying MTA and the | |||
receiving MUA, this could allow an attacker to change the information | receiving MUA, this could allow an attacker to change the information | |||
displayed to an end user from an apparently trusted source. | displayed to an end user from an apparently trusted source. | |||
For example, if attackers can append information to a "text/html" | For example, if attackers can append information to a "text/html" | |||
body part, they may be able to exploit a bug in some MUAs that | body part, they may be able to exploit a bug in some MUAs that | |||
continue to read after a "</html>" marker, and thus display HTML text | continue to read after a "</html>" marker, and thus display HTML text | |||
on top of already displayed text. If a message has a | on top of already displayed text. If a message has a "multipart/ | |||
"multipart/alternative" body part, they might be able to add a new | alternative" body part, they might be able to add a new body part | |||
body part that is preferred by the displaying MUA. | that is preferred by the displaying MUA. | |||
8.1.2. Addition of new HTML content to existing content | 8.1.2. Addition of new HTML content to existing content | |||
Several receiving MUA implementations do not cease display after a | Several receiving MUA implementations do not cease display after a | |||
""</html>"" tag. In particular, this allows attacks involving | ""</html>"" tag. In particular, this allows attacks involving | |||
overlaying images on top of existing text. | overlaying images on top of existing text. | |||
INFORMATIVE EXAMPLE: Appending the following text to an existing, | INFORMATIVE EXAMPLE: Appending the following text to an existing, | |||
properly closed message will in many MUAs result in inappropriate | properly closed message will in many MUAs result in inappropriate | |||
data being rendered on top of existing, correct data: | data being rendered on top of existing, correct data: | |||
<div style="position: relative; bottom: 350px; z-index: 2;"> | <div style="position: relative; bottom: | |||
<img src="http://www.ietf.org/images/ietflogo2e.gif" | 350px; z-index: 2;"> <img | |||
width=578 height=370> | src="http://www.ietf.org/images/ietflogo2e.gif" | |||
</div> | width=578 height=370> </div> | |||
8.2. Misappropriated Private Key | 8.2. Misappropriated Private Key | |||
If the private key for a user is resident on their computer and is | If the private key for a user is resident on their computer and is | |||
not protected by an appropriately secure mechanism, it is possible | not protected by an appropriately secure mechanism, it is possible | |||
for malware to send mail as that user and any other user sharing the | for malware to send mail as that user and any other user sharing the | |||
same private key. The malware would not, however, be able to | same private key. The malware would not, however, be able to | |||
generate signed spoofs of other signers' addresses, which would aid | generate signed spoofs of other signers' addresses, which would aid | |||
in identification of the infected user and would limit the | in identification of the infected user and would limit the | |||
possibilities for certain types of attacks involving socially | possibilities for certain types of attacks involving socially | |||
skipping to change at page 55, line 9 | skipping to change at page 59, line 19 | |||
OpenPGP [RFC2440] and S/MIME [RFC3851] address those requirements. | OpenPGP [RFC2440] and S/MIME [RFC3851] address those requirements. | |||
A second security issue related to the DNS revolves around the | A second security issue related to the DNS revolves around the | |||
increased DNS traffic as a consequence of fetching selector-based | increased DNS traffic as a consequence of fetching selector-based | |||
data as well as fetching signing domain policy. Widespread | data as well as fetching signing domain policy. Widespread | |||
deployment of DKIM will result in a significant increase in DNS | deployment of DKIM will result in a significant increase in DNS | |||
queries to the claimed signing domain. In the case of forgeries on a | queries to the claimed signing domain. In the case of forgeries on a | |||
large scale, DNS servers could see a substantial increase in queries. | large scale, DNS servers could see a substantial increase in queries. | |||
A specific DNS security issue that should be considered by DKIM | A specific DNS security issue that should be considered by DKIM | |||
verifiers is the name chaining attack described in Section 2.3 of the | verifiers is the name chaining attack described in Section 2.3 of | |||
DNS Threat Analysis [RFC3833]. A DKIM verifier, while verifying a | [RFC3833]. A DKIM verifier, while verifying a DKIM-Signature header | |||
DKIM-Signature header field, could be prompted to retrieve a key | field, could be prompted to retrieve a key record of an attacker's | |||
record of an attacker's choosing. This threat can be minimized by | choosing. This threat can be minimized by ensuring that name | |||
ensuring that name servers, including recursive name servers, used by | servers, including recursive name servers, used by the verifier | |||
the verifier enforce strict checking of "glue" and other additional | enforce strict checking of "glue" and other additional information in | |||
information in DNS responses and are therefore not vulnerable to this | DNS responses and are therefore not vulnerable to this attack. | |||
attack. | ||||
8.5. Replay Attacks | 8.5. Replay Attacks | |||
In this attack, a spammer sends a message to be spammed to an | In this attack, a spammer sends a message to be spammed to an | |||
accomplice, which results in the message being signed by the | accomplice, which results in the message being signed by the | |||
originating MTA. The accomplice resends the message, including the | originating MTA. The accomplice resends the message, including the | |||
original signature, to a large number of recipients, possibly by | original signature, to a large number of recipients, possibly by | |||
sending the message to many compromised machines that act as MTAs. | sending the message to many compromised machines that act as MTAs. | |||
The messages, not having been modified by the accomplice, have valid | The messages, not having been modified by the accomplice, have valid | |||
signatures. | signatures. | |||
skipping to change at page 57, line 35 | skipping to change at page 61, line 47 | |||
example, in the example above any of the domains could potentially | example, in the example above any of the domains could potentially | |||
simply delegate "example.podunk.ca.us" to a server of their choice | simply delegate "example.podunk.ca.us" to a server of their choice | |||
and completely replace all DNS-served information. Note that a | and completely replace all DNS-served information. Note that a | |||
verifier MAY ignore signatures that come from an unlikely domain | verifier MAY ignore signatures that come from an unlikely domain | |||
such as ".com", as discussed in Section 6.1.1. | such as ".com", as discussed in Section 6.1.1. | |||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
[FIPS.180-2.2002] U.S. Department of Commerce, "Secure Hash | [FIPS-180-2-2002] | |||
Standard", FIPS PUB 180-2, August 2002. | U.S. Department of Commerce, "Secure Hash Standard", FIPS | |||
PUB 180-2, August 2002. | ||||
[ITU.X660.1997] "Information Technology - ASN.1 encoding rules: | [ITU-X660-1997] | |||
Specification of Basic Encoding Rules (BER), | "Information Technology - ASN.1 encoding rules: | |||
Canonical Encoding Rules (CER) and Distinguished | Specification of Basic Encoding Rules (BER), Canonical | |||
Encoding Rules (DER)", ITU-T Recommendation X.660, | Encoding Rules (CER) and Distinguished Encoding Rules | |||
1997. | (DER)", 1997. | |||
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
Internet Mail Extensions (MIME) Part One: Format | Extensions (MIME) Part One: Format of Internet Message | |||
of Internet Message Bodies", RFC 2045, | Bodies", RFC 2045, November 1996. | |||
November 1996. | ||||
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail | [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) | |||
Extensions) Part Three: Message header field | Part Three: Message Header Extensions for Non-ASCII Text", | |||
Extensions for Non-ASCII Text", RFC 2047, | RFC 2047, November 1996. | |||
November 1996. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to | [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
Indicate Requirement Levels", BCP 14, RFC 2119, | Extensions (MIME) Part Five: Conformance Criteria and | |||
March 1997. | Examples", RFC 2049, November 1996. | |||
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
RFC 2821, April 2001. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, | [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, | |||
April 2001. | April 2001. | |||
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key | [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, | |||
Cryptography Standards (PKCS) #1: RSA Cryptography | April 2001. | |||
Specifications Version 2.1", RFC 3447, | ||||
February 2003. | ||||
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, | [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography | |||
"Internationalizing Domain Names in Applications | Standards (PKCS) #1: RSA Cryptography Specifications | |||
(IDNA)", RFC 3490, March 2003. | Version 2.1", RFC 3447, February 2003. | |||
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF | [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, | |||
for Syntax Specifications: ABNF", RFC 4234, | "Internationalizing Domain Names in Applications (IDNA)", | |||
October 2005. | RFC 3490, March 2003. | |||
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | ||||
Specifications: ABNF", RFC 4234, October 2005. | ||||
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, | ||||
July 2009. | ||||
9.2. Informative References | 9.2. Informative References | |||
[BONEH03] Proc. 12th USENIX Security Symposium, "Remote | [BONEH03] "Remote Timing Attacks are Practical", Proceedings 12th | |||
Timing Attacks are Practical", 2003. | USENIX Security Symposium, 2003. | |||
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, | [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, | |||
"Security Multiparts for MIME: Multipart/Signed | "Security Multiparts for MIME: Multipart/Signed and | |||
and Multipart/Encrypted", RFC 1847, October 1995. | Multipart/Encrypted", RFC 1847, October 1995. | |||
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for | [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
Writing an IANA Considerations Section in RFCs", | IANA Considerations Section in RFCs", BCP 26, RFC 2434, | |||
BCP 26, RFC 2434, October 1998. | October 1998. | |||
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. | [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, | |||
Thayer, "OpenPGP Message Format", RFC 2440, | "OpenPGP Message Format", RFC 2440, November 1998. | |||
November 1998. | ||||
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths | [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For | |||
for Public Keys Used For Exchanging Symmetric | Public Keys Used For Exchanging Symmetric Keys", BCP 86, | |||
Keys", RFC 3766, April 2004. | RFC 3766, April 2004. | |||
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the | [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain | |||
Domain Name System (DNS)", RFC 3833, August 2004. | Name System (DNS)", RFC 3833, August 2004. | |||
[RFC3851] Ramsdell, B., "S/MIME Version 3 Message | [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail | |||
Specification", RFC 3851, June 1999. | Extensions (S/MIME) Version 3.1 Message Specification", | |||
RFC 3851, July 2004. | ||||
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration | |||
"Registration Procedures for Message Header | Procedures for Message Header Fields", BCP 90, RFC 3864, | |||
Fields", BCP 90, September 2004. | September 2004. | |||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., | [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
and S. Rose, "DNS Security Introduction and | Rose, "DNS Security Introduction and Requirements", | |||
Requirements", RFC 4033, March 2005. | RFC 4033, March 2005. | |||
[RFC4686] Fenton, J., "Analysis of Threats Motivating | [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys | |||
DomainKeys Identified Mail (DKIM)", RFC 4686, | Identified Mail (DKIM)", RFC 4686, September 2006. | |||
September 2006. | ||||
[RFC4870] Delany, M., "Domain-Based Email Authentication | [RFC4870] Delany, M., "Domain-Based Email Authentication Using | |||
Using Public Keys Advertised in the DNS | Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, | |||
(DomainKeys)", RFC 4870, May 2007. | May 2007. | |||
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, | ||||
J., and M. Thomas, "DomainKeys Identified Mail (DKIM) | ||||
Signatures", RFC 4871, May 2007. | ||||
[RFC5451] Kucherawy, M., "Message Header Field for Indicating | ||||
Message Authentication Status", RFC 5451, April 2009. | ||||
Appendix A. Example of Use (INFORMATIVE) | Appendix A. Example of Use (INFORMATIVE) | |||
This section shows the complete flow of an email from submission to | This section shows the complete flow of an email from submission to | |||
final delivery, demonstrating how the various components fit | final delivery, demonstrating how the various components fit | |||
together. The key used in this example is shown in Appendix C. | together. The key used in this example is shown in Appendix C. | |||
A.1. The User Composes an Email | A.1. The User Composes an Email | |||
From: Joe SixPack <joe@football.example.com> | From: Joe SixPack <joe@football.example.com> | |||
To: Suzie Q <suzie@shopping.example.net> | To: Suzie Q <suzie@shopping.example.net> | |||
Subject: Is dinner ready? | Subject: Is dinner ready? | |||
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) | Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) | |||
Message-ID: <20030712040037.46341.5F8J@football.example.com> | Message-ID: <;20030712040037.46341.5F8J@football.example.com> | |||
Hi. | Hi. | |||
We lost the game. Are you hungry yet? | We lost the game. Are you hungry yet? | |||
Joe. | Joe. | |||
A.2. The Email Is Signed | Figure 1: The User Composes an Email | |||
A.2. The Email is Signed | ||||
This email is signed by the example.com outbound email server and now | This email is signed by the example.com outbound email server and now | |||
looks like this: | looks like this: | |||
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com; | DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com; | |||
c=simple/simple; q=dns/txt; i=joe@football.example.com; | c=simple/simple; q=dns/txt; i=joe@football.example.com; | |||
h=Received : From : To : Subject : Date : Message-ID; | h=Received : From : To : Subject : Date : Message-ID; | |||
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; | bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; | |||
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB | b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB | |||
4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut | 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut | |||
KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV | KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV | |||
4bmp/YzhwvcubU4=; | 4bmp/YzhwvcubU4=; | |||
Received: from client1.football.example.com [192.0.2.1] | Received: from client1.football.example.com [192.0.2.1] | |||
by submitserver.example.com with SUBMISSION; | by submitserver.example.com with SUBMISSION; | |||
Fri, 11 Jul 2003 21:01:54 -0700 (PDT) | Fri, 11 Jul 2003 21:01:54 -0700 (PDT) | |||
From: Joe SixPack <joe@football.example.com> | From: Joe SixPack <joe@football.example.com> | |||
To: Suzie Q <suzie@shopping.example.net> | To: Suzie Q <suzie@shopping.example.net> | |||
Subject: Is dinner ready? | Subject: Is dinner ready? | |||
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) | Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) | |||
Message-ID: <20030712040037.46341.5F8J@football.example.com> | Message-ID: <20030712040037.46341.5F8J@football.example.com> | |||
Hi. | Hi. | |||
We lost the game. Are you hungry yet? | We lost the game. Are you hungry yet? | |||
Joe. | Joe. | |||
The Email is Signed | ||||
The signing email server requires access to the private key | The signing email server requires access to the private key | |||
associated with the "brisbane" selector to generate this signature. | associated with the "brisbane" selector to generate this signature. | |||
A.3. The Email Signature Is Verified | A.3. The Email Signature is Verified | |||
The signature is normally verified by an inbound SMTP server or | The signature is normally verified by an inbound SMTP server or | |||
possibly the final delivery agent. However, intervening MTAs can | possibly the final delivery agent. However, intervening MTAs can | |||
also perform this verification if they choose to do so. The | also perform this verification if they choose to do so. The | |||
verification process uses the domain "example.com" extracted from the | verification process uses the domain "example.com" extracted from the | |||
"d=" tag and the selector "brisbane" from the "s=" tag in the DKIM- | "d=" tag and the selector "brisbane" from the "s=" tag in the DKIM- | |||
Signature header field to form the DNS DKIM query for: | Signature header field to form the DNS DKIM query for: | |||
brisbane._domainkey.example.com | brisbane._domainkey.example.com | |||
Signature verification starts with the physically last Received | Signature verification starts with the physically last Received | |||
header field, the From header field, and so forth, in the order | header field, the From header field, and so forth, in the order | |||
listed in the "h=" tag. Verification follows with a single CRLF | listed in the "h=" tag. Verification follows with a single CRLF | |||
followed by the body (starting with "Hi."). The email is canonically | followed by the body (starting with "Hi."). The email is canonically | |||
prepared for verifying with the "simple" method. The result of the | prepared for verifying with the "simple" method. The result of the | |||
query and subsequent verification of the signature is stored (in this | query and subsequent verification of the signature is stored (in this | |||
example) in the X-Authentication-Results header field line. After | example) in the X-Authentication-Results header field line. After | |||
successful verification, the email looks like this: | successful verification, the email looks like this: | |||
skipping to change at page 62, line 6 | skipping to change at page 65, line 23 | |||
brisbane._domainkey.example.com | brisbane._domainkey.example.com | |||
Signature verification starts with the physically last Received | Signature verification starts with the physically last Received | |||
header field, the From header field, and so forth, in the order | header field, the From header field, and so forth, in the order | |||
listed in the "h=" tag. Verification follows with a single CRLF | listed in the "h=" tag. Verification follows with a single CRLF | |||
followed by the body (starting with "Hi."). The email is canonically | followed by the body (starting with "Hi."). The email is canonically | |||
prepared for verifying with the "simple" method. The result of the | prepared for verifying with the "simple" method. The result of the | |||
query and subsequent verification of the signature is stored (in this | query and subsequent verification of the signature is stored (in this | |||
example) in the X-Authentication-Results header field line. After | example) in the X-Authentication-Results header field line. After | |||
successful verification, the email looks like this: | successful verification, the email looks like this: | |||
X-Authentication-Results: shopping.example.net | X-Authentication-Results: shopping.example.net | |||
header.from=joe@football.example.com; dkim=pass | header.from=joe@football.example.com; dkim=pass | |||
Received: from mout23.football.example.com (192.168.1.1) | Received: from mout23.football.example.com (192.168.1.1) | |||
by shopping.example.net with SMTP; | by shopping.example.net with SMTP; | |||
Fri, 11 Jul 2003 21:01:59 -0700 (PDT) | Fri, 11 Jul 2003 21:01:59 -0700 (PDT) | |||
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com; | DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com; | |||
c=simple/simple; q=dns/txt; i=joe@football.example.com; | c=simple/simple; q=dns/txt; i=joe@football.example.com; | |||
h=Received : From : To : Subject : Date : Message-ID; | h=Received : From : To : Subject : Date : Message-ID; | |||
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; | bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; | |||
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB | b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB | |||
4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut | 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut | |||
KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV | KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV | |||
4bmp/YzhwvcubU4=; | 4bmp/YzhwvcubU4=; | |||
Received: from client1.football.example.com [192.0.2.1] | Received: from client1.football.example.com [192.0.2.1] | |||
by submitserver.example.com with SUBMISSION; | by submitserver.example.com with SUBMISSION; | |||
Fri, 11 Jul 2003 21:01:54 -0700 (PDT) | Fri, 11 Jul 2003 21:01:54 -0700 (PDT) | |||
From: Joe SixPack <joe@football.example.com> | From: Joe SixPack <joe@football.example.com> | |||
To: Suzie Q <suzie@shopping.example.net> | To: Suzie Q <suzie@shopping.example.net> | |||
Subject: Is dinner ready? | Subject: Is dinner ready? | |||
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) | Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) | |||
Message-ID: <20030712040037.46341.5F8J@football.example.com> | Message-ID: <20030712040037.46341.5F8J@football.example.com> | |||
Hi. | Hi. | |||
We lost the game. Are you hungry yet? | We lost the game. Are you hungry yet? | |||
Joe. | Joe. | |||
Successful verification | ||||
Appendix B. Usage Examples (INFORMATIVE) | Appendix B. Usage Examples (INFORMATIVE) | |||
DKIM signing and validating can be used in different ways, for | DKIM signing and validating can be used in different ways, for | |||
different operational scenarios. This Appendix discusses some common | different operational scenarios. This Appendix discusses some common | |||
examples. | examples. | |||
NOTE: Descriptions in this Appendix are for informational purposes | NOTE: Descriptions in this Appendix are for informational purposes | |||
only. They describe various ways that DKIM can be used, given | only. They describe various ways that DKIM can be used, given | |||
particular constraints and needs. In no case are these examples | particular constraints and needs. In no case are these examples | |||
intended to be taken as providing explanation or guidance | intended to be taken as providing explanation or guidance | |||
skipping to change at page 67, line 21 | skipping to change at page 70, line 33 | |||
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 SHA256 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. | |||
The "genrsa" step results in the file rsa.private containing the key | The "genrsa" step results in the file rsa.private containing the key | |||
information similar to this: | information similar to this: | |||
-----BEGIN RSA PRIVATE KEY----- | ||||
-----BEGIN RSA PRIVATE KEY----- | MIICXwIBAAKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFC | |||
MIICXwIBAAKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFC | jxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gb | |||
jxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gb | to/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB | |||
to/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB | AoGBALmn+XwWk7akvkUlqb+dOxyLB9i5VBVfje89Teolwc9YJT36BGN/l4e0l6QX | |||
AoGBALmn+XwWk7akvkUlqb+dOxyLB9i5VBVfje89Teolwc9YJT36BGN/l4e0l6QX | /1//6DWUTB3KI6wFcm7TWJcxbS0tcKZX7FsJvUz1SbQnkS54DJck1EZO/BLa5ckJ | |||
/1//6DWUTB3KI6wFcm7TWJcxbS0tcKZX7FsJvUz1SbQnkS54DJck1EZO/BLa5ckJ | gAYIaqlA9C0ZwM6i58lLlPadX/rtHb7pWzeNcZHjKrjM461ZAkEA+itss2nRlmyO | |||
gAYIaqlA9C0ZwM6i58lLlPadX/rtHb7pWzeNcZHjKrjM461ZAkEA+itss2nRlmyO | n1/5yDyCluST4dQfO8kAB3toSEVc7DeFeDhnC1mZdjASZNvdHS4gbLIA1hUGEF9m | |||
n1/5yDyCluST4dQfO8kAB3toSEVc7DeFeDhnC1mZdjASZNvdHS4gbLIA1hUGEF9m | 3hKsGUMMPwJBAPW5v/U+AWTADFCS22t72NUurgzeAbzb1HWMqO4y4+9Hpjk5wvL/ | |||
3hKsGUMMPwJBAPW5v/U+AWTADFCS22t72NUurgzeAbzb1HWMqO4y4+9Hpjk5wvL/ | 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" | |||
skipping to change at page 68, line 29 | skipping to change at page 71, line 51 | |||
"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 | |||
present this information to the user in a way that helps them is a | present this information to the user in a way that helps them is a | |||
matter of continuing human factors usability research. The tendency | matter of continuing human factors usability research. The tendency | |||
is to have the MUA highlight the address associated with this signing | is to have the MUA highlight the SDID, in an attempt to show the user | |||
identity in some way, in an attempt to show the user the address from | the identity that is claiming responsibility for the message. An MUA | |||
which the mail was sent. An MUA might do this with visual cues such | might do this with visual cues such as graphics, or it might include | |||
as graphics, or it might include the address in an alternate view, or | the address in an alternate view, or it might even rewrite the | |||
it might even rewrite the original From address using the verified | original From address using the verified information. Some MUAs | |||
information. Some MUAs might indicate which header fields were | might indicate which header fields were protected by the validated | |||
protected by the validated DKIM signature. This could be done with a | DKIM signature. This could be done with a positive indication on the | |||
positive indication on the signed header fields, with a negative | signed header fields, with a negative indication on the unsigned | |||
indication on the unsigned header fields, by visually hiding the | header fields, by visually hiding the unsigned header fields, or some | |||
unsigned header fields, or some combination of these. If an MUA uses | combination of these. If an MUA uses visual indications for signed | |||
visual indications for signed header fields, the MUA probably needs | header fields, the MUA probably needs to be careful not to display | |||
to be careful not to display unsigned header fields in a way that | unsigned header fields in a way that might be construed by the end | |||
might be construed by the end user as having been signed. If the | user as having been signed. If the message has an l= tag whose value | |||
message has an l= tag whose value does not extend to the end of the | does not extend to the end of the message, the MUA might also hide or | |||
message, the MUA might also hide or mark the portion of the message | mark the portion of the message body that was not signed. | |||
body that was not signed. | ||||
The aforementioned information is not intended to be exhaustive. The | The aforementioned information is not intended to be exhaustive. The | |||
MUA may choose to highlight, accentuate, hide, or otherwise display | MUA may choose to highlight, accentuate, hide, or otherwise display | |||
any other information that may, in the opinion of the MUA author, be | any other information that may, in the opinion of the MUA author, be | |||
deemed important to the end user. | deemed important to the end user. | |||
Appendix E. Acknowledgements | Appendix E. Acknowledgements | |||
The authors wish to thank Russ Allbery, Edwin Aoki, Claus Assmann, | The previous IETF version of DKIM [RFC4871] was edited by: Eric | |||
Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve Bellovin, | Allman, Jon Callas, Mark Delany, Miles Libbey, Jim Fenton and Michael | |||
Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis Dayman, | Thomas. | |||
Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark Fanto, | ||||
Stephen Farrell, Duncan Findlay, Elliot Gillum, Olafur | That specification was the result of an extended, collaborative | |||
effort, including participation by: Russ Allbery, Edwin Aoki, Claus | ||||
Assmann, Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve | ||||
Bellovin, Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis | ||||
Dayman, Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark | ||||
Fanto, Stephen Farrell, Duncan Findlay, Elliot Gillum, Olafur | ||||
Gu[eth]mundsson, Phillip Hallam-Baker, Tony Hansen, Sam Hartman, | Gu[eth]mundsson, Phillip Hallam-Baker, Tony Hansen, Sam Hartman, | |||
Arvel Hathcock, Amir Herzberg, Paul Hoffman, Russ Housley, Craig | Arvel Hathcock, Amir Herzberg, Paul Hoffman, Russ Housley, Craig | |||
Hughes, Cullen Jennings, Don Johnsen, Harry Katz, Murray S. | Hughes, Cullen Jennings, Don Johnsen, Harry Katz, Murray S. | |||
Kucherawy, Barry Leiba, John Levine, Charles Lindsey, Simon | Kucherawy, Barry Leiba, John Levine, Charles Lindsey, Simon | |||
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 for their valuable | Sanders, Rand Wacker, Sam Weiler, and Dan Wing. | |||
suggestions and constructive criticism. | ||||
The DomainKeys specification was a primary source from which this | The earlier DomainKeys was a primary source from which DKIM was | |||
specification has been derived. Further information about DomainKeys | derived. Further information about DomainKeys is at [RFC4870]. | |||
is at [RFC4870]. | ||||
Authors' Addresses | Appendix F. RFC4871bis Changes | |||
Eric Allman | F.1. TO DO | |||
Sendmail, Inc. | ||||
6425 Christie Ave, Suite 400 | ||||
Emeryville, CA 94608 | ||||
USA | ||||
Phone: +1 510 594 5501 | o Revise summary Introduction to reflect "authentic labeling" rather | |||
EMail: eric+dkim@sendmail.org | than "message authentication". | |||
URI: | ||||
Jon Callas | o Review interoperability items to consider dropping unused | |||
PGP Corporation | features. | |||
3460 West Bayshore | ||||
Palo Alto, CA 94303 | ||||
USA | ||||
Phone: +1 650 319 9016 | o Review retention of other parameters, such as l= | |||
EMail: jon@pgp.com | ||||
Mark Delany | ||||
Yahoo! Inc | ||||
701 First Avenue | ||||
Sunnyvale, CA 95087 | ||||
USA | ||||
Phone: +1 408 349 6831 | o "signatures inside parts shouldn't be processed"? | |||
EMail: markd+dkim@yahoo-inc.com | ||||
URI: | ||||
Miles Libbey | F.2. DONE | |||
Yahoo! Inc | ||||
701 First Avenue | ||||
Sunnyvale, CA 95087 | ||||
USA | ||||
EMail: mlibbeymail-mailsig@yahoo.com | o Incorporate Updates RFC | |||
URI: | ||||
Jim Fenton | o Added RFC 5598 reference | |||
Cisco Systems, Inc. | ||||
MS SJ-9/2 | ||||
170 W. Tasman Drive | ||||
San Jose, CA 95134-1706 | ||||
USA | ||||
Phone: +1 408 526 5914 | o Errata ID: 1376 - Verified - sha value for empty bodies | |||
EMail: fenton@cisco.com | ||||
URI: | ||||
Michael Thomas | o Errata ID: 1377 - Verified - no trailing CR-LF | |||
Cisco Systems, Inc. | ||||
MS SJ-9/2 | ||||
170 W. Tasman Drive | ||||
San Jose, CA 95134-1706 | ||||
Phone: +1 408 525 5386 | o Errata ID: 1378 - Verified - no default algorithm | |||
EMail: mat@cisco.com | ||||
Full Copyright Statement | o Errata ID: 1379 - Verified - z= ABNF | |||
Copyright (C) The IETF Trust (2007). | o Errata ID: 1384 - Verified - clarify relaxed step order | |||
This document is subject to the rights, licenses and restrictions | o Errata ID: 1461 - Verified - h= ABNF | |||
contained in BCP 78, and except as set forth therein, the authors | ||||
retain all their rights. | ||||
This document and the information contained herein are provided on an | o Errata ID: 1487 - Verified - v= ABNF | |||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | ||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | ||||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | ||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Intellectual Property | o Errata ID: 1380 - Held for Document Update - x= fudge factor | |||
The IETF takes no position regarding the validity or scope of any | o Errata ID: 1381 - Held for Document Update - unknown q= value, | |||
Intellectual Property Rights or other rights that might be claimed to | h=/k=/s=/t= value | |||
pertain to the implementation or use of the technology described in | ||||
this document or the extent to which any license under such rights | ||||
might or might not be available; nor does it represent that it has | ||||
made any independent effort to identify any such rights. Information | ||||
on the procedures with respect to rights in RFC documents can be | ||||
found in BCP 78 and BCP 79. | ||||
Copies of IPR disclosures made to the IETF Secretariat and any | o Errata ID: 1382 - Held for Document Update - unknown s= values | |||
assurances of licenses to be made available, or the result of an | (dup of 1381) | |||
attempt made to obtain a general license or permission for the use of | ||||
such proprietary rights by implementers or users of this | ||||
specification can be obtained from the IETF on-line IPR repository at | ||||
http://www.ietf.org/ipr. | ||||
The IETF invites any interested party to bring to its attention any | o Errata ID: 1383 - Held for Document Update - add g= example | |||
copyrights, patents or patent applications, or other proprietary | ||||
rights that may cover technology that may be required to implement | ||||
this standard. Please address the information to the IETF at | ||||
ietf-ipr@ietf.org. | ||||
Acknowledgement | o Errata ID: 1386 - Held for Document Update - fix DKIM-Signature | |||
example | ||||
Funding for the RFC Editor function is currently provided by the | o Errata ID: 1532 - Held for Document Update - "v=DKIM1" | |||
Internet Society. | ||||
o Errata ID: 1596 - Held for Document Update - *value* of the b= tag | ||||
o Add Authentication Results RFC 5451 to 6.2 | ||||
Authors' Addresses | ||||
D. Crocker (editor) | ||||
Brandenburg InternetWorking | ||||
675 Spruce Dr. | ||||
Sunnyvale | ||||
USA | ||||
Phone: +1.408.246.8253 | ||||
Email: dcrocker@bbiw.net | ||||
URI: http://bbiw.net | ||||
Tony Hansen (editor) | ||||
AT&T Laboratories | ||||
200 Laurel Ave. South | ||||
Middletown, NJ 07748 | ||||
USA | ||||
Email: tony+dkimov@maillennium.att.com | ||||
M. Kucherawy (editor) | ||||
Cloudmark | ||||
Email: msk@cloudmark.com | ||||
End of changes. 222 change blocks. | ||||
892 lines changed or deleted | 980 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/ |