draft-ietf-dkim-base-03.txt | draft-ietf-dkim-base-04.txt | |||
---|---|---|---|---|
DKIM E. Allman | DKIM E. Allman | |||
Internet-Draft Sendmail, Inc. | Internet-Draft Sendmail, Inc. | |||
Expires: December 27, 2006 J. Callas | Expires: January 16, 2007 J. Callas | |||
PGP Corporation | PGP Corporation | |||
M. Delany | M. Delany | |||
M. Libbey | M. Libbey | |||
Yahoo! Inc | Yahoo! Inc | |||
J. Fenton | J. Fenton | |||
M. Thomas | M. Thomas | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
June 25, 2006 | July 15, 2006 | |||
DomainKeys Identified Mail (DKIM) Signatures | DomainKeys Identified Mail (DKIM) Signatures | |||
draft-ietf-dkim-base-03 | draft-ietf-dkim-base-04 | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 1, line 41 | skipping to change at page 1, line 41 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on December 27, 2006. | This Internet-Draft will expire on January 16, 2007. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
Abstract | Abstract | |||
DomainKeys Identified Mail (DKIM) defines a domain-level | DomainKeys Identified Mail (DKIM) defines a domain-level | |||
authentication framework for email using public-key cryptography and | authentication framework for email using public-key cryptography and | |||
key server technology to permit verification of the source and | key server technology to permit verification of the source and | |||
contents of messages by either Mail Transfer Agents (MTAs) or Mail | contents of messages by either Mail Transfer Agents (MTAs) or Mail | |||
User Agents (MUAs). The ultimate goal of this framework is to permit | User Agents (MUAs). The ultimate goal of this framework is to permit | |||
a signing domain to assert responsibility for a message, thus proving | a signing domain to assert responsibility for a message, thus | |||
and protecting message signer identity and the integrity of the | protecting message signer identity and the integrity of the messages | |||
messages they convey while retaining the functionality of Internet | they convey while retaining the functionality of Internet email as it | |||
email as it is known today. Proof and protection of email identity, | is known today. Protection of email identity may assist in the | |||
including repudiation and non-repudiation, may assist in the global | global control of "spam" and "phishing". | |||
control of "spam" and "phishing". | ||||
Requirements Language | Requirements Language | |||
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]. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.1 Signing Identity . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.2 Signing Identity . . . . . . . . . . . . . . . . . . . . . 6 | 1.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.3 Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 | 1.3 Simple Key Management . . . . . . . . . . . . . . . . . . 6 | |||
1.4 Simple Key Management . . . . . . . . . . . . . . . . . . 6 | ||||
2. Terminology and Definitions . . . . . . . . . . . . . . . . 6 | 2. Terminology and Definitions . . . . . . . . . . . . . . . . 6 | |||
2.1 Signers . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.1 Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2.2 Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.2 Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.3 White Space . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.3 White Space . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.4 Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 7 | 2.4 Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 7 | |||
2.5 Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 8 | 2.5 Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 7 | |||
2.6 DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 8 | 2.6 DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 8 | |||
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . 9 | 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.1 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 9 | 3.1 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.2 Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 11 | 3.2 Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 11 | |||
3.3 Signing and Verification Algorithms . . . . . . . . . . . 12 | 3.3 Signing and Verification Algorithms . . . . . . . . . . . 12 | |||
3.4 Canonicalization . . . . . . . . . . . . . . . . . . . . . 13 | 3.4 Canonicalization . . . . . . . . . . . . . . . . . . . . . 14 | |||
3.5 The DKIM-Signature header field . . . . . . . . . . . . . 18 | 3.5 The DKIM-Signature header field . . . . . . . . . . . . . 18 | |||
3.6 Key Management and Representation . . . . . . . . . . . . 25 | 3.6 Key Management and Representation . . . . . . . . . . . . 26 | |||
3.7 Computing the Message Hashes . . . . . . . . . . . . . . . 30 | 3.7 Computing the Message Hashes . . . . . . . . . . . . . . . 30 | |||
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . 31 | 3.8 Signing by Parent Domains . . . . . . . . . . . . . . . . 32 | |||
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . 32 | ||||
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 32 | 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
5.1 Determine if the Email Should be Signed and by Whom . . . 32 | 5.1 Determine if the Email Should be Signed and by Whom . . . 33 | |||
5.2 Select a private-key and corresponding selector | 5.2 Select a private-key and corresponding selector | |||
information . . . . . . . . . . . . . . . . . . . . . . . 32 | information . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
5.3 Normalize the Message to Prevent Transport Conversions . . 33 | 5.3 Normalize the Message to Prevent Transport Conversions . . 34 | |||
5.4 Determine the header fields to Sign . . . . . . . . . . . 33 | 5.4 Determine the header fields to Sign . . . . . . . . . . . 34 | |||
5.5 Compute the Message Hash and Signature . . . . . . . . . . 35 | 5.5 Compute the Message Hash and Signature . . . . . . . . . . 36 | |||
5.6 Insert the DKIM-Signature header field . . . . . . . . . . 36 | 5.6 Insert the DKIM-Signature header field . . . . . . . . . . 36 | |||
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 37 | 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 37 | |||
6.1 Extract Signatures from the Message . . . . . . . . . . . 37 | 6.1 Extract Signatures from the Message . . . . . . . . . . . 37 | |||
6.2 Communicate Verification Results . . . . . . . . . . . . . 42 | 6.2 Communicate Verification Results . . . . . . . . . . . . . 43 | |||
6.3 Interpret Results/Apply Local Policy . . . . . . . . . . . 42 | 6.3 Interpret Results/Apply Local Policy . . . . . . . . . . . 43 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 44 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 44 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . 44 | 7.1 DKIM-Signature Tag Specifications . . . . . . . . . . . . 44 | |||
8.1 Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 44 | 7.2 DKIM-Signature Query Method Registry . . . . . . . . . . . 45 | |||
8.2 Misappropriated Private Key . . . . . . . . . . . . . . . 45 | 7.3 DKIM-Signature Canonicalization Registry . . . . . . . . . 45 | |||
8.3 Key Server Denial-of-Service Attacks . . . . . . . . . . . 45 | 7.4 _domainkey DNS TXT Record Tag Specifications . . . . . . . 46 | |||
8.4 Attacks Against DNS . . . . . . . . . . . . . . . . . . . 46 | 7.5 DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 47 | |||
8.5 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 46 | 7.6 DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 47 | |||
8.6 Limits on Revoking Keys . . . . . . . . . . . . . . . . . 47 | 8. Security Considerations . . . . . . . . . . . . . . . . . . 47 | |||
8.7 Intentionally malformed Key Records . . . . . . . . . . . 47 | 8.1 Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 47 | |||
8.8 Intentionally Malformed DKIM-Signature header fields . . . 47 | 8.2 Misappropriated Private Key . . . . . . . . . . . . . . . 48 | |||
8.9 Information Leakage . . . . . . . . . . . . . . . . . . . 48 | 8.3 Key Server Denial-of-Service Attacks . . . . . . . . . . . 49 | |||
8.10 Remote Timing Attacks . . . . . . . . . . . . . . . . . 48 | 8.4 Attacks Against DNS . . . . . . . . . . . . . . . . . . . 49 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 | 8.5 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 50 | |||
9.1 Normative References . . . . . . . . . . . . . . . . . . . 48 | 8.6 Limits on Revoking Keys . . . . . . . . . . . . . . . . . 51 | |||
9.2 Informative References . . . . . . . . . . . . . . . . . . 49 | 8.7 Intentionally malformed Key Records . . . . . . . . . . . 51 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 50 | 8.8 Intentionally Malformed DKIM-Signature header fields . . . 51 | |||
A. Example of Use (INFORMATIVE) . . . . . . . . . . . . . . . . 51 | 8.9 Information Leakage . . . . . . . . . . . . . . . . . . . 51 | |||
A.1 The user composes an email . . . . . . . . . . . . . . . . 51 | 8.10 Remote Timing Attacks . . . . . . . . . . . . . . . . . 51 | |||
A.2 The email is signed . . . . . . . . . . . . . . . . . . . 51 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 | |||
A.3 The email signature is verified . . . . . . . . . . . . . 52 | 9.1 Normative References . . . . . . . . . . . . . . . . . . . 52 | |||
B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . . . . . 53 | 9.2 Informative References . . . . . . . . . . . . . . . . . . 52 | |||
B.1 Simple Message Forwarding . . . . . . . . . . . . . . . . 53 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53 | |||
B.2 Outsourced Business Functions . . . . . . . . . . . . . . 53 | A. Example of Use (INFORMATIVE) . . . . . . . . . . . . . . . . 54 | |||
B.3 PDAs and Similar Devices . . . . . . . . . . . . . . . . . 54 | A.1 The user composes an email . . . . . . . . . . . . . . . . 55 | |||
B.4 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 54 | A.2 The email is signed . . . . . . . . . . . . . . . . . . . 55 | |||
B.5 Affinity Addresses . . . . . . . . . . . . . . . . . . . . 55 | A.3 The email signature is verified . . . . . . . . . . . . . 56 | |||
B.6 Third-party Message Transmission . . . . . . . . . . . . . 55 | B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . . . . . 57 | |||
C. Creating a public key (INFORMATIVE) . . . . . . . . . . . . 56 | B.1 Simple Message Forwarding . . . . . . . . . . . . . . . . 57 | |||
D. MUA Considerations . . . . . . . . . . . . . . . . . . . . . 57 | B.2 Outsourced Business Functions . . . . . . . . . . . . . . 57 | |||
E. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 58 | B.3 PDAs and Similar Devices . . . . . . . . . . . . . . . . . 57 | |||
F. Edit History . . . . . . . . . . . . . . . . . . . . . . . . 58 | B.4 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 58 | |||
F.1 Changes since -ietf-02 version . . . . . . . . . . . . . . 58 | B.5 Affinity Addresses . . . . . . . . . . . . . . . . . . . . 58 | |||
F.2 Changes since -ietf-01 version . . . . . . . . . . . . . . 59 | B.6 Third-party Message Transmission . . . . . . . . . . . . . 59 | |||
F.3 Changes since -ietf-00 version . . . . . . . . . . . . . . 60 | B.7 SMTP Servers for Roaming Users . . . . . . . . . . . . . . 59 | |||
F.4 Changes since -allman-01 version . . . . . . . . . . . . . 60 | C. Creating a public key (INFORMATIVE) . . . . . . . . . . . . 59 | |||
F.5 Changes since -allman-00 version . . . . . . . . . . . . . 61 | D. MUA Considerations . . . . . . . . . . . . . . . . . . . . . 61 | |||
Intellectual Property and Copyright Statements . . . . . . . 62 | E. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 62 | |||
F. Edit History . . . . . . . . . . . . . . . . . . . . . . . . 62 | ||||
F.1 Changes since -ietf-03 version . . . . . . . . . . . . . . 62 | ||||
F.2 Changes since -ietf-02 version . . . . . . . . . . . . . . 63 | ||||
F.3 Changes since -ietf-01 version . . . . . . . . . . . . . . 64 | ||||
F.4 Changes since -ietf-00 version . . . . . . . . . . . . . . 65 | ||||
F.5 Changes since -allman-01 version . . . . . . . . . . . . . 66 | ||||
F.6 Changes since -allman-00 version . . . . . . . . . . . . . 66 | ||||
Intellectual Property and Copyright Statements . . . . . . . 67 | ||||
1. Introduction | 1. Introduction | |||
[[Note: text in double square brackets (such as this text) will be | [[Note: text in double square brackets (such as this text) will be | |||
deleted before publication.]] | deleted before publication.]] | |||
1.1 Overview | ||||
DomainKeys Identified Mail (DKIM) defines a mechanism by which email | DomainKeys Identified Mail (DKIM) defines a mechanism by which email | |||
messages can be cryptographically signed, permitting a signing domain | messages can be cryptographically signed, permitting a signing domain | |||
to claim responsibility for the introduction of a message into the | to claim responsibility for the introduction of a message into the | |||
mail stream. Message recipients can verify the signature by querying | mail stream. Message recipients can verify the signature by querying | |||
the signer's domain directly to retrieve the appropriate public key, | the signer's domain directly to retrieve the appropriate public key, | |||
and thereby confirm that the message was attested to by a party in | and thereby confirm that the message was attested to by a party in | |||
possession of the private key for the signing domain. | possession of the private key for the signing domain. | |||
The approach taken by DKIM differs from previous approaches to | The approach taken by DKIM differs from previous approaches to | |||
message signing (e.g. S/MIME [RFC1847], OpenPGP [RFC2440]) in that: | message signing (e.g. S/MIME [RFC1847], OpenPGP [RFC2440]) in that: | |||
skipping to change at page 5, line 34 | skipping to change at page 5, line 32 | |||
neither human recipients nor existing MUA (Mail User Agent) | neither human recipients nor existing MUA (Mail User Agent) | |||
software are confused by signature-related content appearing in | software are confused by signature-related content appearing in | |||
the message body, | the message body, | |||
o there is no dependency on public and private key pairs being | o there is no dependency on public and private key pairs being | |||
issued by well-known, trusted certificate authorities, | issued by well-known, trusted certificate authorities, | |||
o there is no dependency on the deployment of any new Internet | o there is no dependency on the deployment of any new Internet | |||
protocols or services for public key distribution or revocation, | protocols or services for public key distribution or revocation, | |||
o it makes no attempt to include encryption as part of the | o signature verification failure does not result in rejection of the | |||
mechanism. | message, | |||
o no attempt is made to include encryption as part of the mechanism, | ||||
o archival is not a design goal. | ||||
DKIM: | DKIM: | |||
o is compatible with the existing email infrastructure and | o is compatible with the existing email infrastructure and | |||
transparent to the fullest extent possible | transparent to the fullest extent possible | |||
o requires minimal new infrastructure | o requires minimal new infrastructure | |||
o can be implemented independently of clients in order to reduce | o can be implemented independently of clients in order to reduce | |||
deployment time | deployment time | |||
o does not require the use of a trusted third party (such as a | o does not require the use of an additional trusted third party | |||
certificate authority or other entity) which might impose | (such as a certificate authority or other entity) which might | |||
significant costs or introduce delays to deployment | impose significant costs or introduce delays to deployment | |||
o can be deployed incrementally | o can be deployed incrementally | |||
o allows delegation of signing to third parties | ||||
o is not intended be used for archival purposes | ||||
A "selector" mechanism allows multiple keys per domain, including | o allows delegation of signing to third parties | |||
delegation of the right to authenticate a portion of the namespace to | ||||
a trusted third party. | ||||
1.2 Signing Identity | 1.1 Signing Identity | |||
DKIM separates the question of the identity of the signer of the | DKIM separates the question of the identity of the signer of the | |||
message from the purported author of the message. In particular, a | message from the purported author of the message. In particular, a | |||
signature includes the identity of the signer. Verifiers can use the | signature includes the identity of the signer. Verifiers can use the | |||
signing information to decide how they want to process the message. | signing information to decide how they want to process the message. | |||
The signing identity is included as part of the signature header | The signing identity is included as part of the signature header | |||
field. | field. | |||
INFORMATIVE RATIONALE: The signing identity associated with a | INFORMATIVE RATIONALE: The signing identity specified by a DKIM | |||
DKIM signature is not required to match an address in any | signature is not required to match an address in any particular | |||
particular header field because of the broad methods of | header field because of the broad methods of interpretation by | |||
interpretation by recipient mail systems, including MUAs. | recipient mail systems, including MUAs. | |||
1.3 Scalability | 1.2 Scalability | |||
DKIM is designed to support the extreme scalability requirements | DKIM is designed to support the extreme scalability requirements | |||
which characterize the email identification problem. There are | which characterize the email identification problem. There are | |||
currently over 70 million domains and a much larger number of | currently over 70 million domains and a much larger number of | |||
individual addresses. DKIM seeks to preserve the positive aspects of | individual addresses. DKIM seeks to preserve the positive aspects of | |||
the current email infrastructure, such as the ability for anyone to | the current email infrastructure, such as the ability for anyone to | |||
communicate with anyone else without introduction. | communicate with anyone else without introduction. | |||
1.4 Simple Key Management | 1.3 Simple Key Management | |||
DKIM differs from traditional hierarchical public-key systems in that | DKIM differs from traditional hierarchical public-key systems in that | |||
no key signing infrastructure is required; the verifier requests the | no key signing infrastructure is required; the verifier requests the | |||
public key from the claimed signer directly. | public key from the claimed signer directly. | |||
The DNS is proposed as the initial mechanism for publishing public | The DNS is proposed as the initial mechanism for publishing public | |||
keys. DKIM is designed to be extensible to other key fetching | keys. DKIM is designed to be extensible to other key fetching | |||
services as they become available. | services as they become available. | |||
2. Terminology and Definitions | 2. Terminology and Definitions | |||
skipping to change at page 8, line 28 | skipping to change at page 8, line 23 | |||
o "sub-domain" | o "sub-domain" | |||
The following definitions are imported from [RFC2822]: | The following definitions are imported from [RFC2822]: | |||
o "WSP" (space or tab) | o "WSP" (space or tab) | |||
o "FWS" (folding white space) | o "FWS" (folding white space) | |||
o "field-name" (name of a header field) | o "field-name" (name of a header field) | |||
o "dot-atom" (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 | INFORMATIVE NOTE: Be aware that the ABNF in RFC 2045 does not | |||
obey the rules of RFC 4234 and must be interpreted accordingly, | obey the rules of RFC 4234 and must be interpreted accordingly, | |||
particularly as regards case folding. | particularly as regards case folding. | |||
skipping to change at page 10, line 4 | skipping to change at page 9, line 47 | |||
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 | |||
To support multiple concurrent public keys per signing domain, the | To support multiple concurrent public keys per signing domain, the | |||
key namespace is subdivided using "selectors". For example, | key namespace is subdivided using "Selectors". For example, | |||
selectors might indicate the names of office locations (e.g., | Selectors might indicate the names of office locations (e.g., | |||
"sanfrancisco", "coolumbeach", and "reykjavik"), the signing date | "sanfrancisco", "coolumbeach", and "reykjavik"), the signing date | |||
(e.g., "january2005", "february2005", etc.), or even the individual | (e.g., "january2005", "february2005", etc.), or even the individual | |||
user. | user. | |||
Selectors are needed to support some important use cases. For | Selectors are needed to support some important use cases. For | |||
example: | example: | |||
o Domains which want to delegate signing capability for a specific | o Domains which want to delegate signing capability for a specific | |||
address for a given duration to a partner, such as an advertising | address for a given duration to a partner, such as an advertising | |||
provider or other outsourced function. | provider or other out-sourced function. | |||
o Domains which want to allow frequent travelers to send messages | o Domains which want to allow frequent travelers to send messages | |||
locally without the need to connect with a particular MSA. | locally without the need to connect with a particular MSA. | |||
o "Affinity" domains (e.g., college alumni associations) which | o "Affinity" domains (e.g., college alumni associations) which | |||
provide forwarding of incoming mail but which do not operate a | provide forwarding of incoming mail but which do not operate a | |||
mail submission agent for outgoing mail. | mail submission agent for outgoing mail. | |||
Periods are allowed in selectors and are component separators. If | Periods are allowed in Selectors and are component separators. When | |||
keys are stored in DNS, the period defines sub-domain boundaries. | keys are retrieved from the DNS, periods in Selectors define DNS | |||
Sub-selectors might be used to combine dates with locations; for | label boundaries in a manner similar to the conventional use in | |||
example, "march2005.reykjavik". This can be used to allow delegation | domain names. Selector components might be used to combine dates | |||
of a portion of the selector name-space. | with locations; for example, "march2005.reykjavik". In a DNS | |||
implementation, this can be used to allow delegation of a portion of | ||||
the Selector name-space. | ||||
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 | |||
are determined by the domain owner. Many domain owners will be | are determined by the domain owner. Many domain owners will be | |||
satisfied with just one selector whereas administratively distributed | satisfied with just one Selector whereas administratively distributed | |||
organizations may choose to manage disparate selectors and key pairs | organizations may choose to manage disparate Selectors and key pairs | |||
in different regions or on different email servers. | 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 | |||
"january2005" to a public key associated with selector | "january2005" to a public key associated with Selector | |||
"february2005", it merely makes sure that both public keys are | "february2005", it merely makes sure that both public keys are | |||
advertised in the public-key repository concurrently for the | advertised in the public-key repository concurrently for the | |||
transition period during which email may be in transit prior to | transition period during which email may be in transit prior to | |||
verification. At the start of the transition period, the outbound | verification. At the start of the transition period, the outbound | |||
email servers are configured to sign with the "february2005" private- | email servers are configured to sign with the "february2005" private- | |||
key. At the end of the transition period, the "january2005" public | key. At the end of the transition period, the "january2005" public | |||
key is removed from the public-key repository. | key is removed from the public-key repository. | |||
While some domains may wish to make selector values well known, | INFORMATIVE NOTE: A key may also be revoked as described below. | |||
others will want to take care not to allocate selector names in a way | The distinction between revoking and removing a key selector | |||
record is subtle. When phasing out keys as described above, a | ||||
signing domain would probably simply remove the key record after | ||||
the transition period. However, a signing domain could elect to | ||||
revoke the key (but maintain the key record) for a further period. | ||||
There is no defined semantic difference between a revoked key and | ||||
a removed key. | ||||
While some domains may wish to make Selector values well known, | ||||
others will want to take care not to allocate Selector names in a way | ||||
that allows harvesting of data by outside parties. E.g., if per-user | that allows harvesting of data by outside parties. E.g., if per-user | |||
keys are issued, the domain owner will need to make the decision as | keys are issued, the domain owner will need to make the decision as | |||
to whether to associate this selector directly with the user name, or | to whether to associate this Selector directly with the user name, or | |||
make it some unassociated random value, such as a fingerprint of the | make it some unassociated random value, such as a fingerprint of the | |||
public key. | public key. | |||
INFORMATIVE IMPLEMENTERS' NOTE: reusing a selector with a new key | INFORMATIVE IMPLEMENTERS' NOTE: reusing a Selector with a new key | |||
(for example, changing the key associated with a user's name) | (for example, changing the key associated with a user's name) | |||
makes it impossible to tell the difference between a message that | makes it impossible to tell the difference between a message that | |||
didn't verify because the key is no longer valid versus a message | didn't verify because the key is no longer valid versus a message | |||
that is actually forged. Signers should not change the key | that is actually forged. Signers should not change the key | |||
associated with a selector. When creating a new key, signers | associated with a Selector. When creating a new key, signers | |||
should associate it with a new selector. | should associate it with a new Selector. | |||
3.2 Tag=Value Lists | 3.2 Tag=Value Lists | |||
DKIM uses a simple "tag=value" syntax in several contexts, including | DKIM uses a simple "tag=value" syntax in several contexts, including | |||
in messages and domain signature records. | in messages and domain signature records. | |||
Values are a series of strings containing either plain text, base64 | Values are a series of strings containing either plain text, "base64" | |||
text (as defined in [RFC2045], section 6.8), qp-section (ibid, | text (as defined in [RFC2045], section 6.8), "qp-section" (ibid, | |||
section 6.7), or dkim-quoted-printable (as defined above). The name | section 6.7), or "dkim-quoted-printable" (as defined above). The | |||
of the tag will determine the encoding of each value; however, no | name of the tag will determine the encoding of each value; however, | |||
encoding may include the semicolon (";") character, since that | no encoding may include the semicolon (";") character, since that | |||
separates tag-specs. | separates tag-specs. | |||
INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" | ||||
defined below (as "tag-value") only includes 7-bit characters, an | ||||
implementation that wished to anticipate future standards would be | ||||
advised to not preclude the use of UTF8-encoded text in tag=value | ||||
lists. | ||||
Formally, the syntax rules are: | Formally, the syntax rules are: | |||
tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] | tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] | |||
tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] | tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] | |||
tag-name = ALPHA 0*ALNUMPUNC | tag-name = ALPHA 0*ALNUMPUNC | |||
tag-value = [ 1*VALCHAR 0*( 1*(WSP / FWS) 1*VALCHAR ) ] | tag-value = [ 1*VALCHAR 0*( 1*(WSP / FWS) 1*VALCHAR ) ] | |||
; WSP and FWS prohibited at beginning and end | ; WSP and FWS prohibited at beginning and end | |||
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 / "_" | |||
skipping to change at page 12, line 21 | skipping to change at page 12, line 42 | |||
Unrecognized tags MUST be ignored. | Unrecognized tags MUST be ignored. | |||
Tags that have an empty value are not the same as omitted tags. An | Tags that have an empty value are not the same as omitted tags. An | |||
omitted tag is treated as having the default value; a tag with an | omitted tag is treated as having the default value; a tag with an | |||
empty value explicitly designates the empty string as the value. For | empty value explicitly designates the empty string as the value. 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 key signing/verification algorithms. Two | DKIM supports multiple digital signature algorithms. Two algorithms | |||
algorithms are defined by this specification at this time: rsa-sha1, | are defined by this specification at this time: rsa-sha1, and rsa- | |||
and rsa-sha256. The rsa-sha256 algorithm is the default if no | sha256. The rsa-sha256 algorithm is the default if no algorithm is | |||
algorithm is specified. Verifiers MUST implement both rsa-sha1 and | specified. Verifiers MUST implement both rsa-sha1 and rsa-sha256. | |||
rsa-sha256. Signers MUST implement and SHOULD sign using rsa-sha256. | Signers MUST implement and SHOULD sign using rsa-sha256. | |||
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 as the hash-alg. That hash is then | in Section 3.7 below using SHA-1 as the hash-alg. That hash is then | |||
signed by the signer using the RSA algorithm (defined in PKCS#1 | signed by the signer using the RSA algorithm (defined in PKCS#1 | |||
version 1.5 [RFC3447]; in particular see section 5.2) with an | version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. | |||
exponent of 65537 as the crypt-alg and the signer's private key. The | The hash MUST NOT be truncated or converted into any form other than | |||
hash MUST NOT be truncated or converted into any form other than the | the native binary form before being signed. | |||
native binary form before being signed. | ||||
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 as the hash-alg. That hash is | in Section 3.7 below using SHA-256 as the hash-alg. That hash is | |||
then signed by the signer using the RSA algorithm (actually PKCS#1 | then signed by the signer using the RSA algorithm (actually PKCS#1 | |||
version 1.5 [RFC3447]; in particular see section 5.2) with an | version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. | |||
exponent of 65537 as the crypt-alg and the signer's private key. The | The hash MUST NOT be truncated or converted into any form other than | |||
hash MUST NOT be truncated or converted into any form other than the | the native binary form before being signed. | |||
native binary form before being signed. | ||||
3.3.3 Other algorithms | 3.3.3 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 understand. | any signatures using algorithms that they do not implement. | |||
3.3.4 Key sizes | 3.3.4 Key sizes | |||
Selecting appropriate key sizes is a trade-off between cost, | Selecting appropriate key sizes is a trade-off between cost, | |||
performance and risk. Since short RSA keys more easily succumb to | performance and risk. Since short RSA keys more easily succumb to | |||
off-line attacks, signers MUST use RSA keys of at least 1024 bits for | off-line attacks, signers MUST use RSA keys of at least 1024 bits for | |||
long-lived keys. Verifiers MUST be able to validate signatures with | long-lived keys. Verifiers MUST be able to validate signatures with | |||
keys ranging from 512 bits to 2048 bits, and they MAY be able to | keys ranging from 512 bits to 2048 bits, and they MAY be able to | |||
validate signatures with larger keys. Security policies may use the | validate signatures with larger keys. Verifier policies may use the | |||
length of the signing key as one metric for determining whether a | length of the signing key as one metric for determining whether a | |||
signature is acceptable. | signature is acceptable. | |||
Factors that should influence the key size choice include: | Factors that should influence the key size choice include: | |||
o The practical constraint that large keys may not fit within a 512 | o The practical constraint that large keys may not fit within a 512 | |||
byte DNS UDP response packet | byte DNS UDP response packet | |||
o The security constraint that keys smaller than 1024 bits are | o The security constraint that keys smaller than 1024 bits are | |||
subject to off-line attacks | subject to off-line attacks | |||
o Larger keys impose higher CPU costs to verify and sign email | o Larger keys impose higher CPU costs to verify and sign email | |||
o Keys can be replaced on a regular basis, thus their lifetime can | o Keys can be replaced on a regular basis, thus their lifetime can | |||
be relatively short | be relatively short | |||
o The security goals of this specification are modest compared to | o The security goals of this specification are modest compared to | |||
typical goals of public-key systems | typical goals of public-key systems | |||
See RFC3766 [RFC3766] for further discussion of selecting key sizes. | See [RFC3766] for further discussion of selecting key sizes. | |||
3.4 Canonicalization | 3.4 Canonicalization | |||
Empirical evidence demonstrates that some mail servers and relay | Empirical evidence demonstrates that some mail servers and relay | |||
systems modify email in transit, potentially invalidating a | systems modify email in transit, potentially invalidating a | |||
signature. There are two competing perspectives on such | signature. There are two competing perspectives on such | |||
modifications. For most signers, mild modification of email is | modifications. For most signers, mild modification of email is | |||
immaterial to the authentication status of the email. For such | 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 an authentication failure. These signers prefer a | minor, result in a signature verification failure. These signers | |||
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 | |||
are unwilling to accept any modification to the body of messages. | are unwilling to accept any modification to the body of messages. | |||
To satisfy all requirements, two canonicalization algorithms are | To satisfy all requirements, two canonicalization algorithms are | |||
defined for each of the header and the body: a "simple" algorithm | defined for each of the header and the body: a "simple" algorithm | |||
that tolerates almost no modification and a "relaxed" algorithm that | that tolerates almost no modification and a "relaxed" algorithm that | |||
tolerates common modifications such as white-space replacement and | tolerates common modifications such as white-space replacement and | |||
header field line re-wrapping. A signer MAY specify either algorithm | header field line re-wrapping. A signer MAY specify either algorithm | |||
for header or body when signing an email. If no canonicalization | for header or body when signing an email. If no canonicalization | |||
algorithm is specified by the signer, the "simple" algorithm defaults | algorithm is specified by the signer, the "simple" algorithm defaults | |||
for both header and body. Verifiers MUST implement both | for both header and body. Verifiers MUST implement both | |||
canonicalization algorithms. Further canonicalization algorithms MAY | canonicalization algorithms. Note that the header and body may use | |||
be defined in the future; verifiers MUST ignore any signatures that | different canonicalization algorithms. Further canonicalization | |||
use unrecognized canonicalization algorithms. | algorithms MAY be defined in the future; verifiers MUST ignore any | |||
signatures that use unrecognized canonicalization algorithms. | ||||
In all cases, the header fields of the message are presented to the | [[WORKING GROUP DISCUSSION POINT: If a message is transmitted | |||
signing algorithm first in the order indicated by the signature | using CHUNKING (that is, BDAT instead of the DATA command) and | |||
header field and canonicalized using the indicated algorithm. Only | BODY=BINARYMIME [RFC3030] then the body should be treated as a | |||
header fields listed as signed in the signature header field are | binary stream, and no canonicalization whatsoever should be done. | |||
included. Note: the signature header field itself is presented at | Do we want to leave this for the future, say that canonicalization | |||
the end of the hash, not with the other headers. The CRLF separating | is ignored in this circumstance, or add a third "binary" body | |||
the header field from the body is then presented, followed by the | canonicalization algorithm? Or something else, of course.]] | |||
canonicalized body. Note that the header and body may use different | ||||
canonicalization algorithms. | ||||
Canonicalization simply prepares the email for presentation to the | Canonicalization simply prepares the email for presentation to the | |||
signing or verification algorithm. It MUST NOT change the | signing or verification algorithm. It MUST NOT change the | |||
transmitted data in any way. Canonicalization of header fields and | transmitted data in any way. Canonicalization of header fields and | |||
body are described below. | body are described below. | |||
NOTE: This section assumes that the message is already in "network | NOTE: This section assumes that the message is already in "network | |||
normal" format (e.g., text is ASCII encoded, lines are separated with | normal" format (e.g., text is ASCII encoded, lines are separated with | |||
CRLF characters, etc.). See also Section 5.3 for information about | CRLF characters, etc.). See also Section 5.3 for information about | |||
normalizing the message. | normalizing the message. | |||
skipping to change at page 15, line 26 | skipping to change at page 15, line 44 | |||
value. | value. | |||
o Delete any WSP characters remaining before and after the colon | o Delete any WSP characters remaining before and after the colon | |||
separating the header field name from the header field value. The | separating the header field name from the header field value. The | |||
colon separator MUST be retained. | colon separator MUST be retained. | |||
3.4.3 The "simple" Body Canonicalization Algorithm | 3.4.3 The "simple" Body Canonicalization Algorithm | |||
The "simple" body canonicalization algorithm ignores all empty lines | The "simple" body canonicalization algorithm ignores all empty lines | |||
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. It makes no other | length after removal of the line terminator. If there is no trailing | |||
changes to the message body. In more formal terms, the "simple" body | CRLF on the message, a CRLF is added. It makes no other changes to | |||
canonicalization algorithm reduces "CRLF 0*CRLF" at the end of the | the message body. In more formal terms, the "simple" body | |||
body to a single "CRLF". | canonicalization algorithm converts "0*CRLF" at the end of the body | |||
to a single "CRLF". | ||||
3.4.4 The "relaxed" Body Canonicalization Algorithm | 3.4.4 The "relaxed" Body Canonicalization Algorithm | |||
[[This section may be deleted; see discussion below.]] The "relaxed" | [[This section may be deleted; see discussion below.]] The "relaxed" | |||
body canonicalization algorithm: | body canonicalization algorithm: | |||
o Ignores all white space at the end of lines. Implementations MUST | o Ignores all white space at the end of lines. Implementations MUST | |||
NOT remove the CRLF at the end of the line. | NOT remove the CRLF at the end of the line. | |||
o Reduces all sequences of WSP within a line to a single SP | o Reduces all sequences of WSP within a line to a single SP | |||
character. | character. | |||
o Ignores all empty lines at the end of the message body. "Empty | o Ignores all empty lines at the end of the message body. "Empty | |||
line" is defined in Section 3.4.3. | line" is defined in Section 3.4.3. | |||
[[NON-NORMATIVE DISCUSSION: The authors are undecided whether to | [[WORKING GROUP DISCUSSION POINT (ISSUE 1326): Mike Thomas has | |||
leave the "relaxed" body canonicalization algorithm in to the | found bare CRs in the wild that are getting converted to CRLF by | |||
specification or delete it entirely. We believe that for the vast | some MTAs and thus breaking signatures. Shall we (a) drop | |||
majority of cases, the "simple" body canonicalization algorithm | "relaxed" until we can figure out how to do it right and then put | |||
should be sufficient. We simply do not have enough data to know | it in as an extension, (b) change "relaxed" to handle this case, | |||
whether to retain the "relaxed" body canonicalization algorithm or | probably by having it convert bare CR and LF to CRLF, or (c) | |||
not.]] | something else?]] | |||
3.4.5 Body Length Limits | 3.4.5 Body Length Limits | |||
A body length count MAY be specified to limit the signature | A body length count MAY be specified to limit the signature | |||
calculation to an initial prefix of the body text, measured in | calculation to an initial prefix of the body text, measured in | |||
octets. If the body length count is not specified then the entire | octets. If the body length count is not specified then the entire | |||
message body is signed and verified. | message body is signed. | |||
INFORMATIVE IMPLEMENTATION NOTE: Body length limits could be | ||||
useful in increasing signature robustness when sending to a | ||||
mailing list that both appends to content sent to it and does not | ||||
sign its messages. However, using such limits enables an attack | ||||
in which an attacker 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. To avoid this attack, signers should be wary of using | ||||
this tag, and verifiers might wish to ignore the tag or remove | ||||
text that appears after the specified content length, perhaps | ||||
based on other criteria. | ||||
The body length count allows the signer of a message to permit data | ||||
to be appended to the end of the body of a signed message. The body | ||||
length count is made following the canonicalization algorithm; for | ||||
example, any white space ignored by a canonicalization algorithm is | ||||
not included as part of the body length count. | ||||
INFORMATIVE RATIONALE: This capability is provided because it is | INFORMATIVE RATIONALE: This capability is provided because it is | |||
very common for mailing lists to add trailers to messages (e.g., | very common for mailing lists to add trailers to messages (e.g., | |||
instructions how to get off the list). Until those messages are | instructions how to get off the list). Until those messages are | |||
also signed, the body length count is a useful tool for the | also signed, the body length count is a useful tool for the | |||
verifier since it may as a matter of policy accept messages having | verifier since it may as a matter of policy accept messages having | |||
valid signatures with extraneous data. | valid signatures with extraneous data. | |||
Signers of MIME messages that include a body length count SHOULD be | INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables | |||
sure that the length extends to the closing MIME boundary string. | an attack in which an attacker 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. To avoid this attack, signers should be wary of using | ||||
this tag, and verifiers might wish to ignore the tag or remove | ||||
text that appears after the specified content length, perhaps | ||||
based on other criteria. | ||||
The body length count allows the signer of a message to permit data | ||||
to be appended to the end of the body of a signed message. The body | ||||
length count MUST be calculated following the canonicalization | ||||
algorithm; for example, any white space ignored by a canonicalization | ||||
algorithm is not included as part of the body length count. Signers | ||||
of MIME messages that include a body length count SHOULD be sure that | ||||
the length extends to the closing MIME boundary string. | ||||
INFORMATIVE IMPLEMENTATION NOTE: A signer wishing to ensure that | INFORMATIVE IMPLEMENTATION NOTE: A signer wishing to ensure that | |||
the only acceptable modifications are to add to the MIME postlude | the only acceptable modifications are to add to the MIME postlude | |||
would use a body length count encompassing the entire final MIME | would use a body length count encompassing the entire final MIME | |||
boundary string, including the final "--CRLF". A signer wishing | boundary string, including the final "--CRLF". A signer wishing | |||
to allow additional MIME parts but not modification of existing | to allow additional MIME parts but not modification of existing | |||
parts would use a body length count extending through the final | parts would use a body length count extending through the final | |||
MIME boundary string, omitting the final "--CRLF". | MIME boundary string, omitting the final "--CRLF". | |||
A body length count of zero means that the body is completely | A body length count of zero means that the body is completely | |||
unsigned. | unsigned. | |||
INFORMATIVE IMPLEMENTATION NOTE: Note that verifiers may choose | ||||
to modify their interpretation of messages with unsigned content, | ||||
including truncating the unsigned part, refusing to display the | ||||
unsigned part to the user, or simply treating the signature as | ||||
invalid. | ||||
Signers wishing to ensure that no modification of any sort can occur | Signers wishing to ensure that no modification of any sort can occur | |||
should specify the "simple" algorithm and omit the body length count. | should specify the "simple" canonicalization algorithm for both | |||
header and body and omit the body length count. | ||||
3.4.6 Canonicalization Examples (INFORMATIVE) | 3.4.6 Canonicalization Examples (INFORMATIVE) | |||
(In the following examples, actual white space is used only for | (In the following examples, actual white space is used only for | |||
clarity. The actual input and output text is designated using | clarity. The actual input and output text is designated using | |||
bracketed descriptors: "<SP>" for a space character, "<TAB>" for a | bracketed descriptors: "<SP>" for a space character, "<TAB>" 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.) | |||
skipping to change at page 17, line 37 | skipping to change at page 18, line 4 | |||
<CRLF> | <CRLF> | |||
<SP> C <SP><CRLF> | <SP> C <SP><CRLF> | |||
D <SP><TAB><SP> E <CRLF> | D <SP><TAB><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> | |||
(postamble) | ||||
Example 2: The same message canonicalized using simple | Example 2: The same message canonicalized using simple | |||
canonicalization for both header and body results in a header | canonicalization for both header and body results in a header | |||
reading: | reading: | |||
A: <SP> X <CRLF> | A: <SP> X <CRLF> | |||
B <SP> : <SP> Y <TAB><CRLF> | B <SP> : <SP> Y <TAB><CRLF> | |||
<TAB> Z <SP><SP><CRLF> | <TAB> Z <SP><SP><CRLF> | |||
and a body reading: | and a body reading: | |||
<SP> C <SP><CRLF> | <SP> C <SP><CRLF> | |||
D <SP><TAB><SP> E <CRLF> | D <SP><TAB><SP> E <CRLF> | |||
(postamble) | ||||
Example 3: When processed using relaxed header canonicalization and | Example 3: When processed using relaxed header canonicalization and | |||
simple body canonicalization, the canonicalized version has a header | simple body canonicalization, the canonicalized version has a header | |||
of: | of: | |||
a:X <CRLF> | a:X <CRLF> | |||
b:Y <SP> Z <CRLF> | b:Y <SP> Z <CRLF> | |||
and a body reading: | and a body reading: | |||
<SP> C <SP><CRLF> | <SP> C <SP><CRLF> | |||
D <SP><TAB><SP> E <CRLF> | D <SP><TAB><SP> E <CRLF> | |||
(postamble) | ||||
3.5 The DKIM-Signature header field | 3.5 The DKIM-Signature header field | |||
The signature of the email is stored in the "DKIM-Signature:" header | The signature of the email is stored in the "DKIM-Signature:" header | |||
field. This header field contains all of the signature and key- | field. This header field contains all of the signature and key- | |||
fetching data. The DKIM-Signature value is a tag-list as described | fetching data. The DKIM-Signature value is a tag-list as described | |||
in Section 3.2. | in Section 3.2. | |||
The "DKIM-Signature:" header field SHOULD be treated as though it | The "DKIM-Signature:" header field SHOULD be treated as though it | |||
were a trace header field as defined in section 3.6 of [RFC2822], and | were a trace header field as defined in section 3.6 of [RFC2822], and | |||
hence SHOULD NOT be reordered and SHOULD be prepended to the message. | hence SHOULD NOT be reordered and SHOULD be prepended to the message. | |||
In particular, the "DKIM-Signature" header field SHOULD precede the | ||||
original email header fields presented to the canonicalization and | ||||
signature algorithms. | ||||
The "DKIM-Signature:" header field being created or verified is | The "DKIM-Signature:" header field being created or verified is | |||
always included in the signature calculation, after the body of the | always included in the signature calculation, after the body of the | |||
message; however, when calculating or verifying the signature, the | message; however, when calculating or verifying the signature, the | |||
value of the b= tag (signature value) of that DKIM-Signature header | value of the b= tag (signature value) of that DKIM-Signature header | |||
field MUST be treated as though it were the null string. Unknown | field MUST be treated as though it were an empty string. Unknown | |||
tags in the "DKIM-Signature:" header field MUST be included in the | tags in the "DKIM-Signature:" header field MUST be included in the | |||
signature calculation but MUST be otherwise ignored by verifiers. | signature calculation but MUST be otherwise ignored by verifiers. | |||
Other "DKIM-Signature:" header fields that are included in the | Other "DKIM-Signature:" header fields that are included in the | |||
signature should be treated as normal header fields; in particular, | signature should be treated as normal header fields; in particular, | |||
the b= tag is not treated specially. | the b= tag is not treated specially. | |||
The encodings for each field type are listed below. Tags described | The encodings for each field type are listed below. Tags described | |||
as qp-section are as described in section 6.7 of MIME Part One | as qp-section are as described in section 6.7 of MIME Part One | |||
[RFC2045], with the additional conversion of semicolon characters to | [RFC2045], with the additional conversion of semicolon characters to | |||
"=3B"; intuitively, this is one line of quoted-printable encoded | "=3B"; intuitively, this is one line of quoted-printable encoded | |||
text. Tags described as dkim-quoted-printable are as defined above. | text. Tags described as dkim-quoted-printable are as 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. Defined tags are described | requirement status are shown below. Unrecognized tags MUST be | |||
below. Unrecognized tags MUST be ignored. | ignored. | |||
v= Version (MUST be included). This tag defines the version of | v= Version (MUST be included). This tag defines the version of this | |||
this specification that applies to the signature record. It MUST | specification that applies to the signature record. It MUST have | |||
have the value 0.3. | the value 0.4. | |||
ABNF: | ABNF: | |||
sig-v-tag = %x76 [FWS] "=" [FWS] "0.3" | sig-v-tag = %x76 [FWS] "=" [FWS] "0.4" | |||
INFORMATIVE NOTE: DKIM-Signature version numbers are | INFORMATIVE NOTE: DKIM-Signature version numbers are | |||
expected to increase arithmetically as new versions of this | expected to increase arithmetically as new versions of this | |||
specification are released. | specification are released. | |||
[[INFORMATIVE NOTE: Upon publication, this version number | [[INFORMATIVE NOTE: Upon publication, this version number | |||
should be changed to "1", and this note should be deleted.]] | should be changed to "1", and this note should be deleted.]] | |||
a= The algorithm used to generate the signature (plain-text; | a= The algorithm used to generate the signature (plain-text; | |||
REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; | REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; | |||
skipping to change at page 20, line 4 | skipping to change at page 20, line 9 | |||
this value and MUST be ignored when re-assembling the original | this value and MUST be ignored when re-assembling the original | |||
signature. In particular, the signing process can safely insert | signature. In particular, the signing process can safely insert | |||
FWS in this value in arbitrary places to conform to line-length | FWS in this value in arbitrary places to conform to line-length | |||
limits. See Signer Actions (Section 5) for how the signature is | limits. See Signer Actions (Section 5) for how the signature is | |||
computed. | computed. | |||
ABNF: | ABNF: | |||
sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data | sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data | |||
sig-b-tag-data = base64string | sig-b-tag-data = base64string | |||
bh= The hash of the body part of the message (base64; REQUIRED). | ||||
Whitespace is ignored in this value and MUST be ignored when re- | bh= The hash of the canonicalized body part of the message as limited | |||
assembling the original signature. In particular, the signing | by the "l=" tag (base64; REQUIRED). Whitespace is ignored in | |||
process can safely insert FWS in this value in arbitrary places | this value and MUST be ignored when re-assembling the original | |||
to conform to line-length limits. See Section 3.7 for how the | signature. In particular, the signing process can safely insert | |||
body hash is computed. | FWS in this value in arbitrary places to conform to line-length | |||
limits. See Section 3.7 for how the body hash is computed. | ||||
ABNF: | ABNF: | |||
sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data | sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data | |||
sig-bh-tag-data = base64string | sig-bh-tag-data = base64string | |||
c= Message canonicalization (plain-text; OPTIONAL, default is | c= Message canonicalization (plain-text; OPTIONAL, default is | |||
"simple/simple"). This tag informs the verifier of the type of | "simple/simple"). This tag informs the verifier of the type of | |||
canonicalization used to prepare the message for signing. It | canonicalization used to prepare the message for signing. It | |||
consists of two names separated by a "slash" (%d47) character, | consists of two names separated by a "slash" (%d47) character, | |||
skipping to change at page 20, line 33 | skipping to change at page 20, line 39 | |||
header and "simple" is used for the body. For example, | header and "simple" is used for the body. For example, | |||
"c=relaxed" is treated the same as "c=relaxed/simple". | "c=relaxed" is treated the same as "c=relaxed/simple". | |||
ABNF: | ABNF: | |||
sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg | sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg | |||
["/" sig-c-tag-alg] | ["/" sig-c-tag-alg] | |||
sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg | sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg | |||
x-sig-c-tag-alg = hyphenated-word ; for later extension | x-sig-c-tag-alg = hyphenated-word ; for later extension | |||
d= The domain of the signing entity (plain-text; REQUIRED). This | d= The domain of the signing entity (plain-text; REQUIRED). This is | |||
is the domain that will be queried for the public key. This | the domain that will be queried for the public key. This domain | |||
domain MUST be the same as or a parent domain of the "i=" tag | MUST be the same as or a parent domain of the "i=" tag (the | |||
(the signing identity, as described below). If the "t=s" tag is | signing identity, as described below), or it MUST meet the | |||
specified in the key record referenced by the selector in the | requirements for parent domain signing described in Section 3.8. | |||
"s=" tag, then the domain in the "d=" tag must be identical to | When presented with a signature that does not meet these | |||
the domain specified in the "i=" tag. When presented with a | requirement, verifiers MUST consider the signature invalid. | |||
signature that does not meet these requirement, verifiers MUST | ||||
consider the signature invalid. | ||||
Internationalized domain names MUST be punycode-encoded | Internationalized domain names MUST be punycode-encoded | |||
[RFC3492]. | [RFC3492]. | |||
ABNF: | ABNF: | |||
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name | sig-d-tag = %x64 [FWS] "=" [FWS] domain-name | |||
domain-name = sub-domain 1*("." sub-domain) | domain-name = sub-domain 1*("." sub-domain) | |||
; from RFC 2821 Domain, but excluding address-literal | ; from RFC 2821 Domain, but excluding address-literal | |||
h= Signed header fields (plain-text, but see description; | h= Signed header fields (plain-text, but see description; REQUIRED). | |||
REQUIRED). A colon-separated list of header field names that | A colon-separated list of header field names that identify the | |||
identify the header fields presented to the signing algorithm. | header fields presented to the signing algorithm. The field MUST | |||
The field MUST contain the complete list of header fields in the | contain the complete list of header fields in the order presented | |||
order presented to the signing algorithm. The field MAY contain | to the signing algorithm. The field MAY contain names of header | |||
names of header fields that do not exist when signed; nonexistent | fields that do not exist when signed; nonexistent header fields | |||
header fields do not contribute to the signature computation | do not contribute to the signature computation (that is, they are | |||
(that is, they are treated as the null input, including the | treated as the null input, including the header field name, the | |||
header field name, the separating colon, the header field value, | separating colon, the header field value, and any CRLF | |||
and any CRLF terminator). The field MUST NOT include the DKIM- | terminator). The field MUST NOT include the DKIM-Signature | |||
Signature header field that is being created or verified, but may | header field that is being created or verified, but may include | |||
include others. Folding white space (FWS) MAY be included on | others. Folding white space (FWS) MAY be included on either side | |||
either side of the colon separator. Header field names MUST be | of the colon separator. Header field names MUST be compared | |||
compared against actual header field names in a case insensitive | against actual header field names in a case insensitive manner. | |||
manner. This list MUST NOT be empty. See Section 5.4 for a | This list MUST NOT be empty. See Section 5.4 for a discussion of | |||
discussion of choosing header fields to sign. | choosing header fields to sign. | |||
ABNF: | ABNF: | |||
sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name | sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name | |||
0*( *FWS ":" *FWS hdr-name ) | 0*( *FWS ":" *FWS hdr-name ) | |||
hdr-name = field-name | hdr-name = field-name | |||
INFORMATIVE EXPLANATION: By "signing" header fields that do | INFORMATIVE EXPLANATION: By "signing" header fields that do | |||
not actually exist, a signer can prevent insertion of those | not actually exist, a signer can prevent insertion of those | |||
header fields before verification. However, since a signer | header fields before verification. However, since a signer | |||
skipping to change at page 22, line 5 | skipping to change at page 22, line 13 | |||
actual header field with a null value. | actual header field with a null value. | |||
i= Identity of the user or agent (e.g., a mailing list manager) on | i= Identity of the user or agent (e.g., a mailing list manager) on | |||
behalf of which this message is signed (dkim-quoted-printable; | behalf of which this message is signed (dkim-quoted-printable; | |||
OPTIONAL, default is an empty local-part followed by an "@" | OPTIONAL, default is an empty local-part followed by an "@" | |||
followed by the domain from the "d=" tag). The syntax is a | followed by the domain from the "d=" tag). The syntax is a | |||
standard email address where the local-part MAY be omitted. The | standard email address where the local-part MAY be omitted. The | |||
domain part of the address MUST be the same as or a subdomain of | domain part of the address MUST be the same as or a subdomain of | |||
the value of the "d=" tag. | the value of the "d=" tag. | |||
Internationalized domain names MUST be punycode-encoded | ||||
[RFC3492]. | ||||
ABNF: | ABNF: | |||
sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" domain-name | sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" domain-name | |||
INFORMATIVE NOTE: The local-part of the "i=" tag is optional | INFORMATIVE NOTE: The local-part of the "i=" tag is optional | |||
because in some cases a signer may not be able to establish a | because in some cases a signer may not be able to establish a | |||
verified individual identity. In such cases, the signer may | verified individual identity. In such cases, the signer may | |||
wish to assert that although it is willing to go as far as | wish to assert that although it is willing to go as far as | |||
signing for the domain, it is unable or unwilling to commit | signing for the domain, it is unable or unwilling to commit | |||
to an individual user name within their domain. It can do so | to an individual user name within their domain. It can do so | |||
skipping to change at page 22, line 35 | skipping to change at page 22, line 46 | |||
complex topic and trust mechanisms are subject to highly | complex topic and trust mechanisms are subject to highly | |||
creative attacks. The real-world efficacy of any but the | creative attacks. The real-world efficacy of any but the | |||
most basic bindings between the "i=" value and other | most basic bindings between the "i=" value and other | |||
identities is not well established, nor is its vulnerability | identities is not well established, nor is its vulnerability | |||
to subversion by an attacker. Hence reliance on the use of | to subversion by an attacker. Hence reliance on the use of | |||
these options should be strictly limited. In particular it | these options should be strictly limited. In particular it | |||
is not at all clear to what extent a typical end-user | is not at all clear to what extent a typical end-user | |||
recipient can rely on any assurances that might be made by | recipient can rely on any assurances that might be made by | |||
successful use of the "i=" options. | successful use of the "i=" options. | |||
l= Body length count (plain-text unsigned decimal integer; | l= Body length count (plain-text unsigned decimal integer; OPTIONAL, | |||
OPTIONAL, default is entire body). This tag informs the verifier | default is entire body). This tag informs the verifier of the | |||
of the number of octets in the body of the email after | number of octets in the body of the email after canonicalization | |||
canonicalization included in the cryptographic hash, starting | included in the cryptographic hash, starting from 0 immediately | |||
from 0 immediately following the CRLF preceding the body. This | following the CRLF preceding the body. This value MUST NOT be | |||
value MUST NOT be larger than the actual number of octets in the | larger than the actual number of octets in the canonicalized | |||
canonicalized message body. | message body. | |||
INFORMATIVE IMPLEMENTATION WARNING: Use of the l= tag might | INFORMATIVE IMPLEMENTATION WARNING: Use of the l= tag might | |||
allow display of fraudulent content without appropriate | allow display of fraudulent content without appropriate | |||
warning to end users. The l= tag is intended for increasing | warning to end users. The l= tag is intended for increasing | |||
signature robustness when sending to mailing lists that both | signature robustness when sending to mailing lists that both | |||
modify their content and do not sign their messages. | modify their content and do not sign their messages. | |||
However, using the l= tag enables attacks in which an | However, using the l= tag enables attacks in which an | |||
intermediary with malicious intent modifies a message to | intermediary with malicious intent modifies a message to | |||
include content that solely benefits the attacker. It is | include content that solely benefits the attacker. It is | |||
possible for the appended content to completely replace the | possible for the appended content to completely replace the | |||
skipping to change at page 23, line 42 | skipping to change at page 24, line 9 | |||
Currently the only valid value is "dns/txt" which defines the DNS | Currently the only valid value is "dns/txt" which defines the DNS | |||
TXT record lookup algorithm described elsewhere in this document. | TXT record lookup algorithm described elsewhere in this document. | |||
The only option defined for the "dns" query type is "txt", which | The only option defined for the "dns" query type is "txt", which | |||
MUST be included. Verifiers and signers MUST support "dns/txt". | MUST be included. Verifiers and signers MUST support "dns/txt". | |||
ABNF: | ABNF: | |||
sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method | sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method | |||
*([FWS] ":" [FWS] sig-q-tag-method) | *([FWS] ":" [FWS] sig-q-tag-method) | |||
sig-q-tag-method = "txt/dns" / x-sig-q-tag-type ["/" x-sig-q-tag-args] | sig-q-tag-method = "dns/txt" / x-sig-q-tag-type ["/" x-sig-q-tag-args] | |||
x-sig-q-tag-type = hyphenated-word ; for future extension | x-sig-q-tag-type = hyphenated-word ; for future extension | |||
x-sig-q-tag-args = qp-hdr-value | x-sig-q-tag-args = qp-hdr-value | |||
s= The selector subdividing the namespace for the "d=" (domain) tag | ||||
s= The Selector subdividing the namespace for the "d=" (domain) tag | ||||
(plain-text; REQUIRED). | (plain-text; REQUIRED). | |||
ABNF: | ABNF: | |||
sig-s-tag = %x73 [FWS] "=" [FWS] subdomain *( "." sub-domain ) | sig-s-tag = %x73 [FWS] "=" [FWS] selector | |||
t= Signature Timestamp (plain-text unsigned decimal integer; | t= Signature Timestamp (plain-text unsigned decimal integer; | |||
RECOMMENDED, default is an unknown creation time). The time that | RECOMMENDED, default is an unknown creation time). The time that | |||
this signature was created. The format is the number of seconds | this signature was created. The format is the number of seconds | |||
since 00:00:00 on January 1, 1970 in the UTC time zone. The | since 00:00:00 on January 1, 1970 in the UTC time zone. The | |||
value is expressed as an unsigned integer in decimal ASCII. This | value is expressed as an unsigned integer in decimal ASCII. This | |||
value is not constrained to fit into a 31- or 32-bit integer. | value is not constrained to fit into a 31- or 32-bit integer. | |||
Implementations SHOULD be prepared to handle values up to at | Implementations SHOULD be prepared to handle values up to at | |||
least 10^12 (until approximately AD 200,000; this fits into 40 | least 10^12 (until approximately AD 200,000; this fits into 40 | |||
bits). To avoid denial of service attacks, implementations MAY | bits). To avoid denial of service attacks, implementations MAY | |||
skipping to change at page 25, line 4 | skipping to change at page 25, line 11 | |||
if that time is reliably available; otherwise the current time | if that time is reliably available; otherwise the current time | |||
should be used. The value of the "x=" tag MUST be greater than | should be used. The value of the "x=" tag MUST be greater than | |||
the value of the "t=" tag if both are present. | the value of the "t=" tag if both are present. | |||
INFORMATIVE NOTE: The x= tag is not intended as an anti- | INFORMATIVE NOTE: The x= tag is not intended as an anti- | |||
replay defense. | replay defense. | |||
ABNF: | ABNF: | |||
sig-x-tag = %x78 [FWS] "=" [FWS] 1*12DIGIT | sig-x-tag = %x78 [FWS] "=" [FWS] 1*12DIGIT | |||
z= Copied header fields (dkim-quoted-printable, but see | ||||
description; OPTIONAL, default is null). A vertical-bar- | z= Copied header fields (dkim-quoted-printable, but see description; | |||
separated list of selected header fields present when the message | OPTIONAL, default is null). A vertical-bar-separated list of | |||
was signed, including both the field name and value. It is not | selected header fields present when the message was signed, | |||
required to include all header fields present at the time of | including both the field name and value. It is not required to | |||
signing. This field need not contain the same header fields | include all header fields present at the time of signing. This | |||
listed in the "h=" tag. The header field text itself must encode | field need not contain the same header fields listed in the "h=" | |||
the vertical bar ("|", %x7C) character (i.e., vertical bars in | tag. The header field text itself must encode the vertical bar | |||
the z= text are metacharacters, and any actual vertical bar | ("|", %x7C) character (i.e., vertical bars in the z= text are | |||
characters in a copied header field must be encoded). Note that | metacharacters, and any actual vertical bar characters in a | |||
all white space must be encoded, including white space between | copied header field must be encoded). Note that all white space | |||
the colon and the header field value. After encoding, SWSP MAY | must be encoded, including white space between the colon and the | |||
be added at arbitrary locations in order to avoid excessively | header field value. After encoding, SWSP MAY be added at | |||
long lines; such white space is NOT part of the value of the | arbitrary locations in order to avoid excessively long lines; | |||
header field, and MUST be removed before decoding. | such white space is NOT part of the value of the header field, | |||
and MUST be removed before decoding. | ||||
Verifiers MUST NOT use the header field names or copied values | Verifiers MUST NOT use the header field names or copied values | |||
for checking the signature in any way. Copied header field | for checking the signature in any way. Copied header field | |||
values are for diagnostic use only. | values are for diagnostic use only. | |||
Header fields with characters requiring conversion (perhaps from | Header fields with characters requiring conversion (perhaps from | |||
legacy MTAs which are not [RFC2822] compliant) SHOULD be | legacy MTAs which are not [RFC2822] compliant) SHOULD be | |||
converted as described in MIME Part Three [RFC2047]. | converted as described in MIME Part Three [RFC2047]. | |||
ABNF: | ABNF: | |||
skipping to change at page 25, line 41 | skipping to change at page 25, line 49 | |||
sig-z-tag-copy = hdr-name ":" qp-hdr-value | sig-z-tag-copy = hdr-name ":" qp-hdr-value | |||
qp-hdr-value = dkim-quoted-printable ; with "|" encoded | qp-hdr-value = dkim-quoted-printable ; with "|" encoded | |||
INFORMATIVE EXAMPLE of a signature header field spread across | INFORMATIVE EXAMPLE of a signature header field spread across | |||
multiple continuation lines: | multiple continuation lines: | |||
DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane; | DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane; | |||
c=simple; q=dns/txt; i=@eng.example.net; t=1117574938; x=1118006938; | c=simple; q=dns/txt; i=@eng.example.net; t=1117574938; x=1118006938; | |||
h=from:to:subject:date; | h=from:to:subject:date; | |||
z=From:foo@eng.example.net|To:joe@example.com| | z=From:foo@eng.example.net|To:joe@example.com| | |||
Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700 | Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700; | |||
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; | ||||
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ | b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ | |||
VoG4ZHRNiYzR | VoG4ZHRNiYzR | |||
3.6 Key Management and Representation | 3.6 Key Management and Representation | |||
Signature applications require some level of assurance that the | Signature applications require some level of assurance that the | |||
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 responsible signer (the "d=" tag of | (the "q=" tag), the domain of the responsible signer (the "d=" tag of | |||
the DKIM-Signature header field), and the selector (the "s=" tag). | the DKIM-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 key-value-list as described in Section 3.2. | The overall syntax is a tag-list as described in Section 3.2. The | |||
The current valid tags are described below. Other tags MAY be | current valid tags are described below. Other tags MAY be present | |||
present and MUST be ignored by any implementation that does not | and MUST be ignored by any implementation that does not understand | |||
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 | |||
response. Responses beginning with a "v=" tag with any other | record. Records beginning with a "v=" tag with any other value | |||
value MUST be discarded. | MUST be discarded. | |||
ABNF: | ABNF: | |||
key-v-tag = %x76 [FWS] "=" [FWS] "DKIM1" | key-v-tag = %x76 [FWS] "=" [FWS] "DKIM1" | |||
g= granularity of the key (plain-text; OPTIONAL, default is "*"). | g= granularity of the key (plain-text; OPTIONAL, default is "*"). | |||
This value MUST match the Local-part of the "i=" tag of the DKIM- | 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 | Signature header field (or its default value of the empty string | |||
if "i=" is not specified), with a "*" character matching a | if "i=" is not specified), with a "*" character matching a | |||
sequence of zero or more arbitrary characters ("wildcarding"). | sequence of zero or more arbitrary characters ("wildcarding"). | |||
The intent of this tag is to constrain which signing address can | The intent of this tag is to constrain which signing address can | |||
legitimately use this selector. An email with a signing address | legitimately use this Selector. An email with a signing address | |||
that does not match the value of this tag constitutes a failed | that does not match the value of this tag constitutes a failed | |||
verification. Wildcarding allows matching for addresses such as | verification. Wildcarding allows matching for addresses such as | |||
"user+*". An empty "g=" value never matches any addresses. | "user+*". An empty "g=" value never matches any addresses. | |||
ABNF: | ABNF: | |||
key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart | key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart | |||
key-g-tag-lpart = [dot-atom] ["*"] [dot-atom] | key-g-tag-lpart = [dot-atom-text] ["*"] [dot-atom-text] | |||
[[NON-NORMATIVE DISCUSSION POINT: "*" is legal in a dot- | [[NON-NORMATIVE DISCUSSION POINT: "*" is legal in a "dot- | |||
atom. This should probably use a different character for | atom-text". This should probably use a different character | |||
wildcarding. Unfortunately, the options are non-mnemonic | for wildcarding. Unfortunately, the options are non-mnemonic | |||
(e.g., "@", "(", ":"). Alternatively we could insist on | (e.g., "@", "(", ":"). Alternatively we could insist on | |||
escaping a "*" intended as a literal "*" in the address.]] | escaping a "*" intended as a literal "*" in the address.]] | |||
h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to | h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to | |||
allowing all algorithms). A colon-separated list of hash | allowing all algorithms). A colon-separated list of hash | |||
algorithms that might be used. Signers and Verifiers MUST | algorithms that might be used. Signers and Verifiers MUST | |||
support the "sha1" hash algorithm. | support the "sha256" hash algorithm. Verifiers MUST also support | |||
the "sha1" hash algorithm. | ||||
ABNF: | ABNF: | |||
key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg | key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg | |||
0*( [FWS] ":" [FWS] key-h-tag-alg ) | 0*( [FWS] ":" [FWS] key-h-tag-alg ) | |||
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 | k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and | |||
verifiers MUST support the "rsa" key type. The "rsa" key type | verifiers MUST support the "rsa" key type. The "rsa" key type | |||
indicates that an RSA public key, as defined in [RFC3447], | indicates that an ASN.1 DER-encoded [X.660] RSAPublicKey | |||
sections 3.1 and A.1.1, is being used in the p= tag. (Note: the | [RFC3447] (see sections 3.1 and A.1.1) is being used in the p= | |||
p= tag further encodes the value using the base64 algorithm.) | tag. (Note: the p= tag further encodes the value using the | |||
base64 algorithm.) | ||||
ABNF: | ABNF: | |||
key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type | key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type | |||
key-k-tag-type = "rsa" / x-key-k-tag-type | key-k-tag-type = "rsa" / x-key-k-tag-type | |||
x-key-k-tag-type = hyphenated-word ; for future extension | x-key-k-tag-type = hyphenated-word ; for future extension | |||
[[NON-NORMATIVE DISCUSSION NOTE: In some cases it can be | [[NON-NORMATIVE DISCUSSION NOTE: In some cases it can be | |||
hard to separate h= and k=; for example DSA implies that | hard to separate h= and k=; for example DSA implies that | |||
SHA-1 will be used. This might be an actual change to the | SHA-1 will be used. This might be an actual change to the | |||
spec depending on how we decide to fix this.]] | spec depending on how we decide to fix this.]] | |||
n= Notes that might be of interest to a human (qp-section; | ||||
OPTIONAL, default is empty). No interpretation is made by any | n= Notes that might be of interest to a human (qp-section; OPTIONAL, | |||
program. This tag should be used sparingly in any key server | default is empty). No interpretation is made by any program. | |||
mechanism that has space limitations (notably DNS). | This tag should be used sparingly in any key server mechanism | |||
that has space limitations (notably DNS). | ||||
ABNF: | ABNF: | |||
key-n-tag = %x6e [FWS] "=" [FWS] qp-section | key-n-tag = %x6e [FWS] "=" [FWS] qp-section | |||
p= Public-key data (base64; REQUIRED). An empty value means that | p= Public-key data (base64; REQUIRED). An empty value means that | |||
this public key has been revoked. The syntax and semantics of | this public key has been revoked. The syntax and semantics of | |||
this tag value before being encoded in base64 is defined by the | this tag value before being encoded in base64 is defined by the | |||
k= tag. | k= tag. | |||
ABNF: | ABNF: | |||
key-p-tag = %x70 [FWS] "=" [FWS] base64string | key-p-tag = %x70 [FWS] "=" [ [FWS] base64string ] | |||
s= Service Type (plain-text; OPTIONAL; default is "*"). A colon- | s= Service Type (plain-text; OPTIONAL; default is "*"). A colon- | |||
separated list of service types to which this record applies. | separated list of service types to which this record applies. | |||
Verifiers for a given service type MUST ignore this record if the | Verifiers for a given service type MUST ignore this record if the | |||
appropriate type is not listed. Currently defined service types | appropriate type is not listed. Currently defined service types | |||
are: | are: | |||
* matches all service types | * matches all service types | |||
email electronic mail (not necessarily limited to SMTP) | email electronic mail (not necessarily limited to SMTP) | |||
skipping to change at page 29, line 16 | skipping to change at page 29, line 23 | |||
y This domain is testing DKIM. Verifiers MUST NOT treat | y This domain is testing DKIM. Verifiers MUST NOT treat | |||
messages from signers in testing mode differently from | messages from signers in testing mode differently from | |||
unsigned email, even should the signature fail to verify. | unsigned email, even should the signature fail to verify. | |||
Verifiers MAY wish to track testing mode results to assist | Verifiers MAY wish to track testing mode results to assist | |||
the signer. | the signer. | |||
s Any DKIM-Signature header fields using the "i=" tag MUST have | s Any DKIM-Signature header fields using the "i=" tag MUST have | |||
the same domain value on the right hand side of the "@" in | the same domain value on the right hand side of the "@" in | |||
the "i=" tag and the value of the "d=" tag. That is, the | the "i=" tag and the value of the "d=" tag. That is, the | |||
"i=" domain MUST NOT be a subdomain of "d=". | "i=" domain MUST NOT be a subdomain of "d=". Use of this | |||
flag is RECOMMENDED unless subdomaining is required. | ||||
ABNF: | ABNF: | |||
key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag | key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag | |||
0*( [FWS] ":" [FWS] key-t-tag-flag ) | 0*( [FWS] ":" [FWS] key-t-tag-flag ) | |||
key-t-tag-flag = "y" / "s" / x-key-t-tag-flag | key-t-tag-flag = "y" / "s" / x-key-t-tag-flag | |||
x-key-t-tag-flag = hyphenated-word ; for future extension | x-key-t-tag-flag = hyphenated-word ; for future extension | |||
Unrecognized flags MUST be ignored. | Unrecognized flags MUST be ignored. | |||
3.6.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 Name Space | 3.6.2.1 Name Space | |||
All DKIM keys are stored in a subdomain named ""_domainkey"". Given | All DKIM keys are stored in a subdomain named "_domainkey". Given a | |||
a DKIM-Signature field with a "d=" tag of ""example.com"" and an "s=" | DKIM-Signature field with a "d=" tag of "example.com" and an "s=" tag | |||
tag of ""sample"", the DNS query will be for | of "foo.bar", the DNS query will be for | |||
""sample._domainkey.example.com"". | "foo.bar._domainkey.example.com". | |||
The value of the "i=" tag is not used by the DNS binding. | Wildcard DNS records (e.g., *.bar._domainkey.example.com) MUST NOT be | |||
used. Note also that wildcards within domains (e.g., | ||||
s._domainkey.*.example.com) are not supported by the DNS. | ||||
3.6.2.2 Resource Record Types for Key Storage | 3.6.2.2 Resource Record Types for Key Storage | |||
The DNS Resource Record type used is specified by an option to the | The DNS Resource Record type used is specified by an option to the | |||
query-type ("q=") tag. The only option defined in this base | query-type ("q=") tag. The only option defined in this base | |||
specification is "txt", indicating the use of a TXT RR record. A | specification is "txt", indicating the use of a TXT RR record. A | |||
later extension of this standard may define another Resource Record | later extension of this standard may define another Resource Record | |||
type, tentatively dubbed "DKK". | type. | |||
TXT records are encoded as described in Section 3.6.1. | TXT records 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 starts with a step of | Both signing and verifying message signatures starts 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 | (Section 5); verifiers will use the parameters specified in the | |||
"DKIM-Signature" header field being verified. In the following | "DKIM-Signature" header field being verified. In the following | |||
skipping to change at page 31, line 15 | skipping to change at page 31, line 27 | |||
When calculating the hash on messages that will be transmitted using | When calculating the hash on messages that will be transmitted using | |||
base64 or quoted-printable encoding, signers MUST compute the hash | base64 or quoted-printable encoding, signers MUST compute the hash | |||
after the encoding. Likewise, the verifier MUST incorporate the | after the encoding. Likewise, the verifier MUST incorporate the | |||
values into the hash before decoding the base64 or quoted-printable | values into the hash before decoding the base64 or quoted-printable | |||
text. However, the hash MUST be computed before transport level | text. However, the hash MUST be computed before transport level | |||
encodings such as SMTP "dot-stuffing." | encodings such as SMTP "dot-stuffing." | |||
With the exception of the canonicalization procedure described in | With the exception of the canonicalization procedure described in | |||
Section 3.4, the DKIM signing process treats the body of messages as | Section 3.4, the DKIM signing process treats the body of messages as | |||
simply a string of characters. DKIM messages MAY be either in plain- | simply a string of octets. DKIM messages MAY be either in plain-text | |||
text or in MIME format; no special treatment is afforded to MIME | or in MIME format; no special treatment is afforded to MIME content. | |||
content. Message attachments in MIME format MUST be included in the | Message attachments in MIME format MUST be included in the content | |||
content which is signed. | which is signed. | |||
More formally, the algorithm for the signature is: | More formally, the algorithm for the signature is: | |||
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 and | "canon_header" and "canon_body" are the canonicalized message header | |||
body (respectively) as defined in Section 3.4 (excluding the DKIM- | and body (respectively) as defined in Section 3.4 (excluding the | |||
Signature header field), and DKIM-SIG is the canonicalized DKIM- | DKIM-Signature header field), and "DKIM-SIG" is the canonicalized | |||
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 NOTE: Many digital signature APIs provide both | ||||
hashing and application of the RSA private key using a single | ||||
"sign()" primitive. When using such an API the last two steps in | ||||
the algorithm would probably be combined into a single call that | ||||
would perform both the "hash-alg" and the "sig-alg". | ||||
3.8 Signing by Parent Domains | ||||
In some circumstances, it is desirable for a domain to apply a | ||||
signature on behalf of any of its subdomains without the need to | ||||
maintain separate selectors (key records) in each subdomain. By | ||||
default, private keys corresponding to key records can be used to | ||||
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 | ||||
messages where the signing identity (i= tag of the signature) is | ||||
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 | ||||
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. If the | ||||
referenced key record contains the "s" flag as part of the t= tag, | ||||
the domain of the signing identity (i= flag) MUST be the same as that | ||||
of the d= domain. If this flag is absent, the domain of the signing | ||||
identity MUST be the same as, or a subdomain of, the d= domain. Key | ||||
records which are not intended for use with subdomains SHOULD specify | ||||
the "s" flag in the t= tag. | ||||
4. Semantics of Multiple Signatures | 4. Semantics of Multiple Signatures | |||
A signer that is adding a signature to a message merely creates a new | A signer that is adding a signature to a message merely creates a new | |||
DKIM-Signature header, using the usual semantics of the h= option. A | DKIM-Signature header, using the usual semantics of the h= option. A | |||
signer MAY sign previously existing DKIM-Signature headers using the | signer MAY sign previously existing DKIM-Signature headers using the | |||
method described in section Section 5.4 to sign trace headers. | method described in section Section 5.4 to sign trace headers. | |||
Signers should be cognizant that signing DKIM-Signature headers may | Signers should be cognizant that signing DKIM-Signature headers may | |||
result in signature failures with intermediaries that do not | result in signature failures with intermediaries that do not | |||
recognize that DKIM-Signature's are trace headers and unwittingly | recognize that DKIM-Signatures are trace headers and unwittingly | |||
reorder them. | reorder them. | |||
When evaluating a message with multiple signatures, a verifier should | When evaluating a message with multiple signatures, a verifier should | |||
evaluate signatures independently and on their own merits. For | evaluate signatures independently and on their own merits. For | |||
example, a verifier that by policy chooses not to accept signatures | example, a verifier that by policy chooses not to accept signatures | |||
with deprecated cryptographic algorithms should consider such | with deprecated cryptographic algorithms should consider such | |||
signatures invalid. As with messages with a single signature, | signatures invalid. As with messages with a single signature, | |||
verifiers are at liberty to use the presence of valid signatures as | verifiers are at liberty to use the presence of valid signatures as | |||
an input to local policy; likewise, the interpretation of multiple | an input to local policy; likewise, the interpretation of multiple | |||
valid signatures in combination is a local policy decision of the | valid signatures in combination is a local policy decision of the | |||
skipping to change at page 32, line 18 | skipping to change at page 33, line 9 | |||
cannot be verified. | cannot be verified. | |||
5. Signer Actions | 5. Signer Actions | |||
The following steps are performed in order by signers. | The following steps are performed in order by signers. | |||
5.1 Determine if the Email Should be Signed and by Whom | 5.1 Determine if the Email Should be Signed and by Whom | |||
A signer can obviously only sign email for domains for which it has a | A signer can obviously only sign email for domains for which it has a | |||
private-key and the necessary knowledge of the corresponding public | private-key and the necessary knowledge of the corresponding public | |||
key and selector information. However there are a number of other | key and Selector information. However there are a number of other | |||
reasons beyond the lack of a private key why a signer could choose | reasons beyond the lack of a private key why a signer could choose | |||
not to sign an email. | not to sign an email. | |||
A SUBMISSION server MAY sign if the submitter is authenticated by | INFORMATIVE NOTE: Signing modules may be incorporated into any | |||
some secure means, e.g., SMTP AUTH. Within a trusted enclave the | portion of the mail system as deemed appropriate, including an | |||
signing address MAY be derived from the header field according to | MUA, a SUBMISSION server, or an MTA. Wherever implemented, | |||
local signer policy. Within a trusted enclave an MTA MAY do the | signers should beware of signing (and thereby asserting | |||
signing. | responsibility for) messages that may be problematic. In | |||
particular, within a trusted enclave the signing address might be | ||||
derived from the header according to local policy; SUBMISSION | ||||
servers might only sign messages from users that are properly | ||||
authenticated and authorized. | ||||
INFORMATIVE IMPLEMENTER ADVICE: SUBMISSION servers should not | INFORMATIVE IMPLEMENTER ADVICE: SUBMISSION servers should not | |||
sign Received header fields if the outgoing gateway MTA obfuscates | sign Received header fields if the outgoing gateway MTA obfuscates | |||
Received header fields, for example to hide the details of | Received header fields, for example to hide the details of | |||
internal topology. | internal topology. | |||
A signer MUST NOT sign an email if it is unwilling to be held | ||||
responsible for the message; in particular, the signer SHOULD ensure | ||||
that the submitter has a bona fide relationship with the signer and | ||||
that the submitter has the right to use the address being claimed. | ||||
If an email cannot be signed for some reason, it is a local policy | If an email cannot be signed for some reason, it is a local policy | |||
decision as to what to do with that email. | decision as to what to do with that email. | |||
5.2 Select a private-key and corresponding selector information | 5.2 Select a private-key and corresponding selector information | |||
This specification does not define the basis by which a signer should | This specification does not define the basis by which a signer should | |||
choose which private-key and selector information to use. Currently, | choose which private-key and Selector information to use. Currently, | |||
all selectors are equal as far as this specification is concerned, so | all Selectors are equal as far as this specification is concerned, so | |||
the decision should largely be a matter of administrative | the decision should largely be a matter of administrative | |||
convenience. Distribution and management of private-keys is also | convenience. Distribution and management of private-keys is also | |||
outside the scope of this document. | outside the scope of this document. | |||
INFORMATIVE OPERATIONS ADVICE: A signer should not sign with a | INFORMATIVE OPERATIONS ADVICE: A signer should not sign with a | |||
private key when the selector containing the corresponding public | private key when the Selector containing the corresponding public | |||
key is expected to be removed before the verifier has an | key is expected to be revoked or removed before the verifier has | |||
opportunity to validate the signature. The signer should | an opportunity to validate the signature. The signer should | |||
anticipate that verifiers may choose to defer validation, perhaps | anticipate that verifiers may choose to defer validation, perhaps | |||
until the message is actually read by the final recipient. In | until the message is actually read by the final recipient. In | |||
particular, when rotating to a new key-pair, signing should | particular, when rotating to a new key-pair, signing should | |||
immediately commence with the new private key and the old public | immediately commence with the new private key and the old public | |||
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 | |||
skipping to change at page 33, line 33 | skipping to change at page 34, line 25 | |||
DKIM algorithm. | DKIM algorithm. | |||
Should the message be submitted to the signer with any local encoding | Should the message be submitted to the signer with any local encoding | |||
that will be modified before transmission, such conversion to | that will be modified before transmission, such conversion to | |||
canonical form MUST be done before signing. In particular, some | canonical form MUST be done before signing. In particular, some | |||
systems use local line separator conventions (such as the Unix | systems use local line separator conventions (such as the Unix | |||
newline character) internally rather than the SMTP-standard CRLF | newline character) internally rather than the SMTP-standard CRLF | |||
sequence. All such local conventions MUST be converted to canonical | sequence. All such local conventions MUST be converted to canonical | |||
format before signing. | format before signing. | |||
More generally, the signer MUST sign the message as it will be | More generally, the signer MUST sign the message as it is expected to | |||
received by the verifier rather than in some local or internal form. | be received by the verifier rather than in some local or internal | |||
form. | ||||
5.4 Determine the header fields to Sign | 5.4 Determine the header fields to Sign | |||
The From header field MUST be signed (that is, included in the h= tag | The From header field MUST be signed (that is, included in the h= tag | |||
of the resulting DKIM-Signature header field); any header field that | of the resulting DKIM-Signature header field). Signers SHOULD NOT | |||
describes the role of the signer (for example, the Sender or Resent- | sign an existing header field likely to be legitimately modified or | |||
From header field if the signature is on behalf of the corresponding | removed in transit. In particular, [RFC2821] explicitly permits | |||
address and that address is different from the From address) MUST | modification or removal of the "Return-Path" header field in transit. | |||
also be included. The signed header fields SHOULD also include the | Signers MAY include any other header fields present at the time of | |||
Subject and Date header fields as well as all MIME header fields. | signing at the discretion of the signer. | |||
Signers SHOULD NOT sign an existing header field likely to be | ||||
legitimately modified or removed in transit. In particular, | INFORMATIVE OPERATIONS NOTE: The choice of which header fields to | |||
[RFC2821] explicitly permits modification or removal of the "Return- | sign is non-obvious. One strategy is to sign all existing, non- | |||
Path" header field in transit. Signers MAY include any other header | repeatable header fields. An alternative strategy is to sign only | |||
fields present at the time of signing at the discretion of the | header fields that are likely to be displayed to or otherwise be | |||
signer. It is RECOMMENDED that all other existing, non-repeatable | likely to affect the processing of the message at the receiver. A | |||
header fields be signed. | third strategy is to sign only "well known" headers. Note that | |||
verifiers may treat unsigned header fields with extreme | ||||
skepticism, including refusing to display them to the end user or | ||||
even ignore the signature if it does not cover certain header | ||||
fields. For this reason signing fields present in the message | ||||
such as Date, Subject, Reply-To, Sender, and all MIME headers is | ||||
highly advised. | ||||
The DKIM-Signature header field is always implicitly signed and MUST | The DKIM-Signature header field is always implicitly signed and MUST | |||
NOT be included in the h= tag except to indicate that other | NOT be included in the h= tag except to indicate that other | |||
preexisting signatures are also signed. | preexisting signatures are also signed. | |||
Signers MUST sign any header fields that the signers wish to assert | ||||
were present at the time of signing. Put another way, verifiers MAY | ||||
treat unsigned header fields with extreme skepticism, up to and | ||||
including refusing to display them to the end user. | ||||
Signers MAY claim to have signed header fields that do not exist | Signers MAY claim to have signed header fields that do not exist | |||
(that is, signers MAY include the header field name in the h= tag | (that is, signers MAY include the header field name in the h= tag | |||
even if that header field does not exist in the message). When | even if that header field does not exist in the message). When | |||
computing the signature, the non-existing header field MUST be | computing the signature, the non-existing header field MUST be | |||
treated as the null string (including the header field name, header | treated as the null string (including the header field name, header | |||
field value, all punctuation, and the trailing CRLF). | field value, all punctuation, and the trailing CRLF). | |||
INFORMATIVE RATIONALE: This allows signers to explicitly assert | INFORMATIVE RATIONALE: This allows signers to explicitly assert | |||
the absence of a header field; if that header field is added later | the absence of a header field; if that header field is added later | |||
the signature will fail. | the signature will fail. | |||
Signers choosing to sign an existing replicated header field (such as | Signers choosing to sign an existing header field that occurs more | |||
Received) MUST sign the physically last instance of that header field | than once in the message (such as Received) MUST sign the physically | |||
in the header field block. Signers wishing to sign multiple | last instance of that header field in the header block. Signers | |||
instances of an existing replicated header field MUST include the | wishing to sign multiple instances of such a header field MUST | |||
header field name multiple times in the h= tag of the DKIM-Signature | include the header field name multiple times in the h= tag of the | |||
header field, and MUST sign such header fields in order from the | DKIM-Signature header field, and MUST sign such header fields in | |||
bottom of the header field block to the top. The signer MAY include | order from the bottom of the header field block to the top. The | |||
more header field names than there are actual corresponding header | signer MAY include more instances of a header field name in h= than | |||
fields to indicate that additional header fields of that name SHOULD | there are actual corresponding header fields to indicate that | |||
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 NOT sign header fields that might be replicated | Signers should be careful of signing header fields that might have | |||
(either at the time of signing or potentially in the future), with | additional instances added later in the delivery process, since such | |||
the exception of trace header fields such as Received. Comment and | header fields might be inserted after the signed instance or | |||
non standard header fields (including X-* header fields) are | otherwise reordered. Trace header fields (such as Received and DKIM- | |||
permitted by [RFC2822] to be replicated; however, many such header | Signature) and Resent-* blocks are the only fields prohibited by | |||
fields are, by convention, not replicated. Signers need to | [RFC2822] from being reordered. | |||
understand the implications of signing header fields that might later | ||||
be replicated, especially in the face of header field reordering. In | ||||
particular, [RFC2822] only requires that trace header fields retain | ||||
the original order. | ||||
INFORMATIVE RATIONALE: Received: is allowed because these header | ||||
fields, as well as Resent-* header fields, are already order- | ||||
sensitive. | ||||
INFORMATIVE ADMONITION: Despite the fact that [RFC2822] permits | INFORMATIVE ADMONITION: Despite the fact that [RFC2822] permits | |||
header field blocks to be reordered (with the exception of | header fields to be reordered (with the exception of Received | |||
Received header fields), reordering of signed replicated header | header fields), reordering of signed header fields with multiple | |||
fields by intermediate MTAs will cause DKIM signatures to be | instances by intermediate MTAs will cause DKIM signatures to be | |||
broken; such anti-social behavior should be avoided. | broken; such anti-social behavior should be avoided. | |||
INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this | INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this | |||
specification, all end-user visible header fields should be signed | specification, all end-user visible header fields should be signed | |||
to avoid possible "indirect spamming." For example, if the | to avoid possible "indirect spamming." For example, if the | |||
"Subject" header field is not signed, a spammer can resend a | "Subject" header field is not signed, a spammer can resend a | |||
previously signed mail, replacing the legitimate subject with a | previously signed mail, replacing the legitimate subject with a | |||
one-line spam. | one-line spam. | |||
INFORMATIVE NOTE: There has been some discussion that a Sender | ||||
Signing Policy include the list of header fields that the signer | ||||
always signs. N.B. In theory this is unnecessary, since as long | ||||
as the signer really always signs the indicated header fields | ||||
there is no possibility of an attacker replaying an existing | ||||
message that has such an unsigned header field. | ||||
5.5 Compute the Message Hash and Signature | 5.5 Compute the Message Hash and Signature | |||
The signer MUST compute the message hash as described in Section 3.7 | The signer MUST compute the message hash as described in Section 3.7 | |||
and then sign it using the selected public-key algorithm. This will | and then sign it using the selected public-key algorithm. This will | |||
result in a DKIM-Signature header field which will include the body | result in a DKIM-Signature header field which will include the body | |||
hash and a signature of the header hash, where that header includes | hash and a signature of the header hash, where that header includes | |||
the DKIM-Signature header field itself. | the DKIM-Signature header field itself. | |||
To avoid possible ambiguity, a signer SHOULD either sign or remove | ||||
any preexisting header fields which convey the results of previous | ||||
verifications of the message signature prior to preparation for | ||||
signing and transmission. Such header fields MUST NOT be signed if | ||||
the signer is uncertain of the authenticity of the preexisting header | ||||
field, for example, if it is not locally generated or signed by a | ||||
previous DKIM-Signature line that the current signer has verified. | ||||
Entities such as mailing list managers that implement DKIM and which | Entities such as mailing list managers that implement DKIM and which | |||
modify the message or a header field (for example, inserting | modify the message or a header field (for example, inserting | |||
unsubscribe information) before retransmitting the message SHOULD | unsubscribe information) before retransmitting the message SHOULD | |||
check any existing signature on input and MUST make such | check any existing signature on input and MUST make such | |||
modifications before re-signing the message; such signing SHOULD | modifications before re-signing the message. | |||
include any prior verification status, if any, that was inserted upon | ||||
message receipt. | ||||
The signer MAY elect to limit the number of bytes of the body that | The signer MAY elect to limit the number of bytes of the body that | |||
will be included in the hash and hence signed. The length actually | will be included in the hash and hence signed. The length actually | |||
hashed should be inserted in the "l=" tag of the "DKIM-Signature" | hashed should be inserted in the "l=" tag of the "DKIM-Signature" | |||
header field. | header field. | |||
INFORMATIVE NOTE: A possible value to include in the "l=" tag | ||||
would include the entire length of the message being signed, | ||||
thereby allowing intermediate agents to append further information | ||||
to the message without breaking the signature (e.g., a mailing | ||||
list manager might add unsubscribe information to the body). A | ||||
signer wishing to permit such intermediate agents to add another | ||||
MIME body part to a "multipart/mixed" message should use a length | ||||
that covers the entire presented message except for the trailing | ||||
"--CRLF" characters; this is known as the "N-4" approach. Note | ||||
that more than four characters may need to be stripped, since | ||||
there could be postlude information that needs to be ignored. | ||||
5.6 Insert the DKIM-Signature header field | 5.6 Insert the DKIM-Signature header field | |||
Finally, the signer MUST insert the "DKIM-Signature:" header field | Finally, the signer MUST insert the "DKIM-Signature:" header field | |||
created in the previous step prior to transmitting the email. The | created in the previous step prior to transmitting the email. The | |||
"DKIM-Signature" header field MUST be the same as used to compute the | "DKIM-Signature" header field MUST be the same as used to compute the | |||
hash as described above, except that the value of the "b=" tag MUST | hash as described above, except that the value of the "b=" tag MUST | |||
be the appropriately signed hash computed in the previous step, | be the appropriately signed hash computed in the previous step, | |||
signed using the algorithm specified in the "a=" tag of the "DKIM- | signed using the algorithm specified in the "a=" tag of the "DKIM- | |||
Signature" header field and using the private key corresponding to | Signature" header field and using the private key corresponding to | |||
the selector given in the "s=" tag of the "DKIM-Signature" header | the Selector given in the "s=" tag of the "DKIM-Signature" header | |||
field, as chosen above in Section 5.2 | field, as chosen above in Section 5.2 | |||
The "DKIM-Signature" MUST be inserted before any other DKIM-Signature | ||||
The "DKIM-Signature" SHOULD be inserted before any header fields that | fields in the header block. | |||
it signs in the header block. | ||||
INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this | INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this | |||
is to insert the "DKIM-Signature" header field at the beginning of | is to insert the "DKIM-Signature" header field at the beginning of | |||
the header block. In particular, it may be placed before any | the header block. In particular, it may be placed before any | |||
existing Received header fields. This is consistent with treating | existing Received header fields. This is consistent with treating | |||
"DKIM-Signature" as a trace header. | "DKIM-Signature" as a trace header. | |||
6. Verifier Actions | 6. Verifier Actions | |||
Since a signer MAY expire a public key at any time, it is recommended | Since a signer MAY remove or revoke a public key at any time, it is | |||
that verification occur in a timely manner with the most timely place | recommended that verification occur in a timely manner with the most | |||
being during acceptance by the border MTA. | timely place being during acceptance by the border MTA. | |||
A border or intermediate MTA MAY verify the message signatures and | A border or intermediate MTA MAY verify the message signature(s). An | |||
add a verification header field to incoming messages. This | MTA who has performed verification MAY communicate the result of that | |||
considerably simplifies things for the user, who can now use an | verification by adding a verification header field to incoming | |||
existing mail user agent. Most MUAs have the ability to filter | messages. This considerably simplifies things for the user, who can | |||
messages based on message header fields or content; these filters | now use an existing mail user agent. Most MUAs have the ability to | |||
would be used to implement whatever policy the user wishes with | filter messages based on message header fields or content; these | |||
respect to unsigned mail. | filters would be used to implement whatever policy the user wishes | |||
with respect to unsigned mail. | ||||
A verifying MTA MAY implement a policy with respect to unverifiable | A verifying MTA MAY implement a policy with respect to unverifiable | |||
mail, regardless of whether or not it applies the verification header | mail, regardless of whether or not it applies the verification header | |||
field to signed messages. | field to signed messages. | |||
Verifiers MUST produce a result that is semantically equivalent to | Verifiers MUST produce a result that is semantically equivalent to | |||
applying the following steps in the order listed. In practice, | applying the following steps in the order listed. In practice, | |||
several of these steps can be performed in parallel in order to | several of these steps can be performed in parallel in order to | |||
improve performance. | improve performance. | |||
skipping to change at page 37, line 48 | skipping to change at page 38, line 4 | |||
For example, one implementation might prefer to try the signatures in | For example, one implementation might prefer to try the signatures in | |||
textual order, whereas another might want to prefer signatures by | textual order, whereas another might want to prefer signatures by | |||
identities that match the contents of the "From" header field over | identities that match the contents of the "From" header field over | |||
other identities. Verifiers MUST NOT attribute ultimate meaning to | other identities. Verifiers MUST NOT attribute ultimate meaning to | |||
the order of multiple DKIM-Signature header fields. In particular, | the order of multiple DKIM-Signature header fields. In particular, | |||
there is reason to believe that some relays will reorder the header | there is reason to believe that some relays will reorder the header | |||
fields in potentially arbitrary ways. | fields in potentially arbitrary ways. | |||
INFORMATIVE IMPLEMENTATION NOTE: Verifiers might use the order as | INFORMATIVE IMPLEMENTATION NOTE: Verifiers might use the order as | |||
a clue to signing order in the absence of any other information. | a clue to signing order in the absence of any other information. | |||
However, other clues as to the semantics of multiple signatures | However, other clues as to the semantics of multiple signatures | |||
must be considered before using ordering. | (such as correlating the signing host with Received headers) may | |||
also be considered. | ||||
A verifier SHOULD NOT treat a message that has one or more bad | A verifier SHOULD NOT treat a message that has one or more bad | |||
signatures and no good signatures differently from a message with no | signatures and no good signatures differently from a message with no | |||
signature at all; this is local policy and is beyond the scope of | signature at all; such treatment is a matter of local policy and is | |||
this document. | beyond the scope of this document. | |||
When a signature successfully verifies, a verifier will either stop | When a signature successfully verifies, a verifier will either stop | |||
processing or attempt to verify any other signatures, at the | processing or attempt to verify any other signatures, at the | |||
discretion of the implementation. | discretion of the implementation. A verifier MAY limit the number of | |||
signatures it tries to avoid denial-of-service attacks. | ||||
INFORMATIVE NOTE: An attacker could send messages with large | ||||
numbers of faulty signatures, each of which would require a DNS | ||||
lookup. This could be an attack on the domain that receives the | ||||
message, by slowing down the verifier by requiring it to do large | ||||
number of DNS lookups and signature verifications. It could also | ||||
be an attack against the domains listed in the signatures, | ||||
essentially by enlisting innocent verifiers in launching an attack | ||||
against the DNS servers of the actual victim. | ||||
In the following description, text reading "return status | In the following description, text reading "return status | |||
(explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL") | (explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL") | |||
means that the verifier MUST immediately cease processing that | means that the verifier MUST immediately cease processing that | |||
signature. The verifier SHOULD proceed to the next signature, if any | signature. The verifier SHOULD proceed to the next signature, if any | |||
is present, and completely ignore the bad signature. If the status | is present, and completely ignore the bad signature. If the status | |||
is "PERMFAIL", the signature failed and should not be reconsidered. | is "PERMFAIL", the signature failed and should not be reconsidered. | |||
If the status is "TEMPFAIL", the signature could not be verified at | If the status is "TEMPFAIL", the signature could not be verified at | |||
this time but may be tried again later. A verifier MAY either defer | this time but may be tried again later. A verifier MAY either defer | |||
the message for later processing, perhaps by queueing it locally or | the message for later processing, perhaps by queueing it locally or | |||
skipping to change at page 39, line 27 | skipping to change at page 39, line 42 | |||
If the DKIM-Signature header field does not contain any of the tags | If the DKIM-Signature header field does not contain any of the tags | |||
listed as required in Section 3.5 the verifier MUST ignore the DKIM- | listed as required in Section 3.5 the verifier MUST ignore the DKIM- | |||
Signature header field and return PERMFAIL (signature missing | Signature header field and return PERMFAIL (signature missing | |||
required tag). | required tag). | |||
If the "DKIM-Signature" header field does not contain the "i=" tag, | If the "DKIM-Signature" header field does not contain the "i=" tag, | |||
the verifier MUST behave as though the value of that tag were "@d", | the verifier MUST behave as though the value of that tag were "@d", | |||
where "d" is the value from the "d=" tag. | where "d" is the value from the "d=" tag. | |||
Verifiers MUST confirm that the domain specified in the "d=" tag is | Verifiers MUST confirm that the domain specified in the "d=" tag is | |||
the same as or a superdomain of the domain part of the "i=" tag. If | the same as or a parent domain of the domain part of the "i=" tag. | |||
not, the DKIM-Signature header field MUST be ignored and the verifier | If not, the DKIM-Signature header field MUST be ignored and the | |||
should return PERMFAIL (domain mismatch). | verifier should return PERMFAIL (domain mismatch). | |||
If the "h=" tag does not include the "From" header field the verifier | ||||
MUST ignore the DKIM-Signature header field and return PERMFAIL (From | ||||
field not signed). | ||||
Verifiers MAY ignore the DKIM-Signature header field and return | Verifiers MAY ignore the DKIM-Signature header field and return | |||
PERMFAIL (signature expired) if it contains an "x=" tag and the | PERMFAIL (signature expired) if it contains an "x=" tag and the | |||
signature has expired. | signature has expired. | |||
Verifiers MAY ignore the DKIM-Signature header field and return | ||||
PERMFAIL (unacceptable signature header) for any other reason, for | ||||
example, if the signature does not sign header fields that the | ||||
verifier views to be essential. As a case in point, if MIME header | ||||
fields are not signed, certain attacks may be possible that the | ||||
verifier would prefer to avoid. | ||||
6.1.2 Get the Public Key | 6.1.2 Get the Public Key | |||
The public key for a signature is needed to complete the verification | The public key for a signature is needed to complete the verification | |||
process. The process of retrieving the public key depends on the | process. The process of retrieving the public key depends on the | |||
query type as defined by the "q=" tag in the "DKIM-Signature:" header | query type as defined by the "q=" tag in the "DKIM-Signature:" header | |||
field. Obviously, a public key need only be retrieved if the process | field. Obviously, a public key need only be retrieved if the process | |||
of extracting the signature information is completely successful. | of extracting the signature information is completely successful. | |||
Details of key management and representation are described in | Details of key management and representation are described in | |||
Section 3.6. The verifier MUST validate the key record and MUST | Section 3.6. The verifier MUST validate the key record and MUST | |||
ignore any public key records that are malformed. | ignore any public key records that are malformed. | |||
When validating a message, a verifier MUST perform the following | When validating a message, a verifier MUST perform the following | |||
steps in a manner that is semantically the same as performing them in | steps in a manner that is semantically the same as performing them in | |||
the order indicated (in some cases the implementation may parallelize | the order indicated (in some cases the implementation may parallelize | |||
or reorder these steps, as long as the semantics remain unchanged): | or reorder these steps, as long as the semantics remain unchanged): | |||
1. Retrieve the public key as described in (Section 3.6) using the | 1. Retrieve the public key as described in (Section 3.6) using the | |||
domain from the "d=" tag and the selector from the "s=" tag. | domain from the "d=" tag and the Selector from the "s=" tag. | |||
2. If the query for the public key fails to respond, the verifier | 2. If the query for the public key fails to respond, the verifier | |||
MAY defer acceptance of this email and return TEMPFAIL (key | MAY defer acceptance of this email and return TEMPFAIL (key | |||
unavailable). If verification is occuring during the incoming | unavailable). If verification is occurring during the incoming | |||
SMTP session, this MAY be achieved with a 451/4.7.5 SMTP reply | SMTP session, this MAY be achieved with a 451/4.7.5 SMTP reply | |||
code. Alternatively, the verifier MAY store the message in the | code. Alternatively, the verifier MAY store the message in the | |||
local queue for later trial or ignore the signature. Note that | local queue for later trial or ignore the signature. Note that | |||
storing a message in the local queue is subject to denial-of- | storing a message in the local queue is subject to denial-of- | |||
service attacks. | service attacks. | |||
3. If the query for the public key fails because the corresponding | 3. If the query for the public key fails because the corresponding | |||
key record does not exist, the verifier MUST immediately return | key record does not exist, the verifier MUST immediately return | |||
PERMFAIL (no key for signature). | PERMFAIL (no key for signature). | |||
skipping to change at page 41, line 9 | skipping to change at page 41, line 34 | |||
domain signature. | domain signature. | |||
7. If the "h=" tag exists in the public key record and the hash | 7. If the "h=" tag exists in the public key record and the hash | |||
algorithm implied by the a= tag in the DKIM-Signature header is | algorithm implied by the a= tag in the DKIM-Signature header is | |||
not included in the contents of the "h=" tag, the verifier MUST | not included in the contents of the "h=" tag, the verifier MUST | |||
ignore the key record and return PERMFAIL (inappropriate hash | ignore the key record and return PERMFAIL (inappropriate hash | |||
algorithm). | algorithm). | |||
8. If the public key data (the "p=" tag) is empty then this key has | 8. If the public key data (the "p=" tag) is empty then this key has | |||
been revoked and the verifier MUST treat this as a failed | been revoked and the verifier MUST treat this as a failed | |||
signature check and return PERMFAIL (key revoked). | signature check and return PERMFAIL (key revoked). There is no | |||
defined semantic difference between a key that has been revoked | ||||
and a key record that has been removed. | ||||
9. If the public key data is not suitable for use with the algorithm | 9. If the public key data is not suitable for use with the algorithm | |||
and key types defined by the "a=" and "k=" tags in the "DKIM- | and key types defined by the "a=" and "k=" tags in the "DKIM- | |||
Signature" header field, the verifier MUST immediately return | Signature" header field, the verifier MUST immediately return | |||
PERMFAIL (inappropriate key algorithm). | PERMFAIL (inappropriate key algorithm). | |||
6.1.3 Compute the Verification | 6.1.3 Compute the Verification | |||
Given a signer and a public key, verifying a signature consists of | Given a signer and a public key, verifying a signature consists of | |||
the following steps. | actions semantically equivalent to the following steps. | |||
1. Based on the algorithm defined in the "c=" tag, the body length | 1. Based on the algorithm defined in the "c=" tag, the body length | |||
specified in the "l=" tag, and the header field names in the "h=" | specified in the "l=" tag, and the header field names in the "h=" | |||
tag, create a canonicalized copy of the email as is described in | tag, prepare a canonicalized version of the message as is | |||
Section 3.7. When matching header field names in the "h=" tag | described in Section 3.7 (note that this version does not | |||
against the actual message header field, comparisons MUST be | actually need to be instantiated). When matching header field | |||
case-insensitive. | names in the "h=" tag against the actual message header field, | |||
comparisons MUST be case-insensitive. | ||||
2. Based on the algorithm indicated in the "a=" tag, compute the | 2. Based on the algorithm indicated in the "a=" tag, compute the | |||
message hashes from the canonical copy as described in | message hashes from the canonical copy as described in | |||
Section 3.7. | Section 3.7. | |||
3. Verify that the hash of the canonicalized message body computed | 3. Verify that the hash of the canonicalized message body computed | |||
in the previous step matches the hash value conveyed in the "bh=" | in the previous step matches the hash value conveyed in the "bh=" | |||
tag. | tag. | |||
4. Using the signature conveyed in the "b=" tag, verify the | 4. Using the signature conveyed in the "b=" tag, verify the | |||
skipping to change at page 42, line 30 | skipping to change at page 43, line 10 | |||
the MIME structure. A simple way to achieve this might be to | the MIME structure. A simple way to achieve this might be to | |||
append "--CRLF" to any "multipart" message with a body length; if | append "--CRLF" to any "multipart" message with a body length; if | |||
the MIME structure is already correctly formed, this will appear | the MIME structure is already correctly formed, this will appear | |||
in the postlude and will not be displayed to the end user. | in the postlude and will not be displayed to the end user. | |||
6.2 Communicate Verification Results | 6.2 Communicate Verification Results | |||
Verifiers wishing to communicate the results of verification to other | Verifiers wishing to communicate the results of verification to other | |||
parts of the mail system may do so in whatever manner they see fit. | parts of the mail system may do so in whatever manner they see fit. | |||
For example, implementations might choose to add an email header | For example, implementations might choose to add an email header | |||
field to the message before passing it on. An example proposal for a | field to the message before passing it on. Any such header field | |||
header field is the Authentication-Results header field [ID-AUTH- | SHOULD be inserted before any existing DKIM-Signature or preexisting | |||
RES]. Any such header field SHOULD be inserted before any existing | authentication status header fields in the header field block. | |||
DKIM-Signature or preexisting authentication status header fields in | ||||
the header field block. | ||||
INFORMATIVE ADVICE to MUA filter writers: Patterns intended to | INFORMATIVE ADVICE to MUA filter writers: Patterns intended to | |||
search for results header fields to visibly mark authenticated | search for results header fields to visibly mark authenticated | |||
mail for end users should verify that such header field was added | mail for end users should verify that such header field was added | |||
by the appropriate verifying domain and that the verified identity | by the appropriate verifying domain and that the verified identity | |||
matches the author identity that will be displayed by the MUA. In | matches the author identity that will be displayed by the MUA. In | |||
particular, MUA filters should not be influenced by bogus results | particular, MUA filters should not be influenced by bogus results | |||
header fields added by attackers. | header fields added by attackers. Verifiers may wish to delete | |||
existing results header fields after verification and before | ||||
adding a new header field to circumvent this attack. | ||||
6.3 Interpret Results/Apply Local Policy | 6.3 Interpret Results/Apply Local Policy | |||
It is beyond the scope of this specification to describe what actions | It is beyond the scope of this specification to describe what actions | |||
a verifier system should make, but an authenticated email presents an | a verifier system should make, but an authenticated email presents an | |||
opportunity to a receiving system that unauthenticated email cannot. | opportunity to a receiving system that unauthenticated email cannot. | |||
Specifically, an authenticated email creates a predictable identifier | Specifically, an authenticated email creates a predictable identifier | |||
by which other decisions can reliably be managed, such as trust and | by which other decisions can reliably be managed, such as trust and | |||
reputation. Conversely, unauthenticated email lacks a reliable | reputation. Conversely, unauthenticated email lacks a reliable | |||
identifier that can be used to assign trust and reputation. It is | identifier that can be used to assign trust and reputation. It is | |||
skipping to change at page 43, line 45 | skipping to change at page 44, line 25 | |||
signed on behalf of any address other than that in the From: header | signed on behalf of any address other than that in the From: header | |||
field, the mail system SHOULD take pains to ensure that the actual | field, the mail system SHOULD take pains to ensure that the actual | |||
signing identity is clear to the reader. | signing identity is clear to the reader. | |||
The verifier MAY treat unsigned header fields with extreme | The verifier MAY treat unsigned header fields with extreme | |||
skepticism, including marking them as untrusted or even deleting them | skepticism, including marking them as untrusted or even deleting them | |||
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 | |||
never there, or was it removed by an over-zealous filter? For | never there, or was it removed by an over-zealous filter? For | |||
diagnostic purposes, the exact reason why the verification fails | diagnostic purposes, the exact reason why the verification fails | |||
SHOULD be made available to the policy module and possibly recorded | SHOULD be made available to the policy module and possibly recorded | |||
in the system logs. However in terms of presentation to the end | in the system logs. However in terms of presentation to the end | |||
user, the result SHOULD be presented as a simple binary result: | user, the result SHOULD be presented as a simple binary result: | |||
either the email is verified or it is not. If the email cannot be | either the email is verified or it is not. If the email cannot be | |||
verified, then it SHOULD be rendered the same as all unverified email | verified, then it SHOULD be rendered the same as all unverified email | |||
regardless of whether it looks like it was signed or not. | regardless of whether it looks like it was signed or not. | |||
7. IANA Considerations | 7. IANA Considerations | |||
To avoid conflicts, tag names for the DKIM-Signature header and key | DKIM introduces some new namespaces that require IANA registry. | |||
records should be registered with IANA. | ||||
Tag values for the "a=", "c=", and "q=" tags in the DKIM-Signature | [[Missing registries for signature t= (flags) tags, as well as key | |||
header field, and the "h=", "k=", "s=", and "t" tags in key records | record s= (service type) and t= (flags).]] | |||
should be registered with IANA for the same reason. | ||||
7.1 DKIM-Signature Tag Specifications | ||||
A DKIM-Signature provides for a list of tag specifications. IANA is | ||||
requested to establish the DKIM Signature Tag Specification Registry, | ||||
for tag specifications that can be used in DKIM-Signature fields and | ||||
that have been specified in any published RFC. | ||||
The initial entries in the registry comprise: | ||||
+------+-----------------+ | ||||
| TYPE | RFC | | ||||
+------+-----------------+ | ||||
| v | (this document) | | ||||
| a | (this document) | | ||||
| b | (this document) | | ||||
| bh | (this document) | | ||||
| c | (this document) | | ||||
| d | (this document) | | ||||
| h | (this document) | | ||||
| i | (this document) | | ||||
| l | (this document) | | ||||
| q | (this document) | | ||||
| s | (this document) | | ||||
| t | (this document) | | ||||
| x | (this document) | | ||||
| z | (this document) | | ||||
+------+-----------------+ | ||||
7.2 DKIM-Signature Query Method Registry | ||||
The "q=" tag-spec, as specified in Section 3.5 provides for a list of | ||||
query methods. | ||||
IANA is requested to establish the DKIM Query Method Registry, for | ||||
mechanisms that can be used to retrieve the key that will permit | ||||
validation processing of a message signed using DKIM and have been | ||||
specified in any published RFC. | ||||
The initial entry in the registry comprises: | ||||
+------+--------+-----------------+ | ||||
| TYPE | OPTION | RFC | | ||||
+------+--------+-----------------+ | ||||
| dns | txt | (this document) | | ||||
+------+--------+-----------------+ | ||||
7.3 DKIM-Signature Canonicalization Registry | ||||
The "c=" tag-spec, as specified in Section 3.5 provides for a | ||||
specifier for canonicalization algorithms for the header and body of | ||||
the message. | ||||
IANA is requested to establish the DKIM Canonicalization Algorithm | ||||
Registry, for algorithms for converting a message into a canonical | ||||
form before signing or verifying using DKIM and have been specified | ||||
in any published RFC. | ||||
The initial entries in the header registry comprise: | ||||
+---------+-----------------+ | ||||
| TYPE | RFC | | ||||
+---------+-----------------+ | ||||
| simple | (this document) | | ||||
| relaxed | (this document) | | ||||
+---------+-----------------+ | ||||
The initial entries in the body registry comprise: | ||||
+---------+-----------------+ | ||||
| TYPE | RFC | | ||||
+---------+-----------------+ | ||||
| simple | (this document) | | ||||
| relaxed | (this document) | | ||||
+---------+-----------------+ | ||||
7.4 _domainkey DNS TXT Record Tag Specifications | ||||
A _domainkey DNS TXT record provides for a list of tag | ||||
specifications. IANA is requested to establish the DKIM _domainkey | ||||
DNS TXT Tag Specification Registry, for tag specifications that can | ||||
be used in DNS TXT Records and that have been specified in any | ||||
published RFC. | ||||
The initial entries in the registry comprise: | ||||
+------+-----------------+ | ||||
| TYPE | RFC | | ||||
+------+-----------------+ | ||||
| v | (this document) | | ||||
| g | (this document) | | ||||
| h | (this document) | | ||||
| k | (this document) | | ||||
| n | (this document) | | ||||
| p | (this document) | | ||||
| s | (this document) | | ||||
| t | (this document) | | ||||
+------+-----------------+ | ||||
7.5 DKIM Key Type Registry | ||||
The "k=" <key-k-tag> (as specified in Section 3.6.1) and the "a=" | ||||
<sig-a-tag-k> (Section 3.5) tags provide for a list of mechanisms | ||||
that can be used to decode a DKIM signature. | ||||
IANA is requested to establish the DKIM Key Type Registry, for such | ||||
mechanisms that have been specified in any published RFC. | ||||
The initial entry in the registry comprises: | ||||
+------+---------+ | ||||
| TYPE | RFC | | ||||
+------+---------+ | ||||
| rsa | RFC3447 | | ||||
+------+---------+ | ||||
7.6 DKIM Hash Algorithms Registry | ||||
The "h=" <key-h-tag> list (specified in Section 3.6.1) and the "a=" | ||||
<sig-a-tag-h> (Section 3.5) provide for a list of mechanisms that can | ||||
be used to produce a digest of message data. | ||||
IANA is requested to establish the DKIM Hash Algorithms Registry, for | ||||
such mechanisms that have been specified in any published RFC. | ||||
The initial entries in the registry comprise: | ||||
+--------+-----+ | ||||
| TYPE | RFC | | ||||
+--------+-----+ | ||||
| sha1 | ? | | ||||
| sha256 | ? | | ||||
+--------+-----+ | ||||
8. Security Considerations | 8. Security Considerations | |||
It has been observed that any mechanism that is introduced which | It has been observed that any mechanism that is introduced which | |||
attempts to stem the flow of spam is subject to intensive attack. | attempts to stem the flow of spam is subject to intensive attack. | |||
DKIM needs to be carefully scrutinized to identify potential attack | DKIM needs to be carefully scrutinized to identify potential attack | |||
vectors and the vulnerability to each. See also [ID-DKIM-THREATS]. | vectors and the vulnerability to each. See also [ID-DKIM-THREATS]. | |||
8.1 Misuse of Body Length Limits ("l=" Tag) | 8.1 Misuse of Body Length Limits ("l=" Tag) | |||
skipping to change at page 44, line 40 | skipping to change at page 48, line 15 | |||
8.1.1 Addition of new MIME parts to multipart/* | 8.1.1 Addition of new MIME parts to multipart/* | |||
If the body length limit does not cover a closing MIME multipart | If the body length limit does not cover a closing MIME multipart | |||
section (including the trailing ""--CRLF"" portion), then it is | section (including the trailing ""--CRLF"" portion), then it is | |||
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. | |||
*** Example appropriate here *** | For example, if an attacker can append information to a "text/html" | |||
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 | ||||
on top of already displayed text. If a message has a "multipart/ | ||||
alternative" body part, they might be able to add a new body part | ||||
that is preferred by the displaying MTA. | ||||
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: | |||
skipping to change at page 45, line 19 | skipping to change at page 48, line 45 | |||
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, however, not be able to | same private key. The malware would, however, not 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- | |||
engineered messages. | engineered messages. This threat applies mainly to MUA-based | |||
implementations; protection of private keys on servers can be easily | ||||
achieved through the use of specialized cryptographic hardware. | ||||
A larger problem occurs if malware on many users' computers obtains | A larger problem occurs if malware on many users' computers obtains | |||
the private keys for those users and transmits them via a covert | the private keys for those users and transmits them via a covert | |||
channel to a site where they can be shared. The compromised users | channel to a site where they can be shared. The compromised users | |||
would likely not know of the misappropriation until they receive | would likely not know of the misappropriation until they receive | |||
"bounce" messages from messages they are purported to have sent. | "bounce" messages from messages they are purported to have sent. | |||
Many users might not understand the significance of these bounce | Many users might not understand the significance of these bounce | |||
messages and would not take action. | messages and would not take action. | |||
One countermeasure is to use a user-entered passphrase to encrypt the | One countermeasure is to use a user-entered passphrase to encrypt the | |||
skipping to change at page 48, line 9 | skipping to change at page 51, line 38 | |||
8.8 Intentionally Malformed DKIM-Signature header fields | 8.8 Intentionally Malformed DKIM-Signature header fields | |||
Verifiers MUST be prepared to receive messages with malformed DKIM- | Verifiers MUST be prepared to receive messages with malformed DKIM- | |||
Signature header fields, and thoroughly verify the header field | Signature header fields, and thoroughly verify the header field | |||
before depending on any of its contents. | before depending on any of its contents. | |||
8.9 Information Leakage | 8.9 Information Leakage | |||
An attacker could determine when a particular signature was verified | An attacker could determine when a particular signature was verified | |||
by using a per-message selector and then monitoring their DNS traffic | by using a per-message Selector and then monitoring their DNS traffic | |||
for the key lookup. This would act as the equivalent of a "web bug" | for the key lookup. This would act as the equivalent of a "web bug" | |||
for verification time rather than when the message was read. | for verification time rather than when the message was read. | |||
8.10 Remote Timing Attacks | 8.10 Remote Timing Attacks | |||
In some cases it may be possible to extract private keys using a | In some cases it may be possible to extract private keys using a | |||
remote timing attack [BONEH03]. Implementations should consider | remote timing attack [BONEH03]. Implementations should consider | |||
obfuscating the timing to prevent such attacks. | obfuscating the timing to prevent such attacks. | |||
9. References | 9. References | |||
skipping to change at page 49, line 5 | skipping to change at page 52, line 35 | |||
Standards (PKCS) #1: RSA Cryptography Specifications | Standards (PKCS) #1: RSA Cryptography Specifications | |||
Version 2.1", RFC 3447, February 2003. | Version 2.1", RFC 3447, February 2003. | |||
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode | [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode | |||
for Internationalized Domain Names in Application(IDNA)", | for Internationalized Domain Names in Application(IDNA)", | |||
March 2003. | March 2003. | |||
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", RFC 4234, October 2005. | Specifications: ABNF", RFC 4234, October 2005. | |||
[X.660] "ITU-T Recommendation X.660 Information Technology - ASN.1 | ||||
encoding rules: Specification of Basic Encoding Rules | ||||
(BER), Canonical Encoding Rules (CER) and Distinguished | ||||
Encoding Rules (DER)", 1997. | ||||
9.2 Informative References | 9.2 Informative References | |||
[BONEH03] Proc. 12th USENIX Security Symposium, "Remote Timing | [BONEH03] Proc. 12th USENIX Security Symposium, "Remote Timing | |||
Attacks are Practical", 2003, <http://www.usenix.org/ | Attacks are Practical", 2003, <http://www.usenix.org/ | |||
publications/library/proceedings/sec03/tech/brumley.html>. | publications/library/proceedings/sec03/tech/brumley.html>. | |||
[ID-AUTH-RES] | ||||
Kucherawy, M., "Message header field for Indicating Sender | ||||
Authentication Status", | ||||
draft-kucherawy-sender-auth-header-02 (work in progress), | ||||
February 2006. | ||||
[ID-DKIM-THREATS] | [ID-DKIM-THREATS] | |||
Fenton, J., "Analysis of Threats Motivating DomainKeys | Fenton, J., "Analysis of Threats Motivating DomainKeys | |||
Identified Mail (DKIM)", draft-fenton-dkim-threats-02 | Identified Mail (DKIM)", draft-fenton-dkim-threats-02 | |||
(work in progress), April 2006. | (work in progress), April 2006. | |||
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, | [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, | |||
"Security Multiparts for MIME: Multipart/Signed and | "Security Multiparts for MIME: Multipart/Signed and | |||
Multipart/Encrypted", RFC 1847, October 1995. | Multipart/Encrypted", RFC 1847, October 1995. | |||
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, | [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, | |||
"OpenPGP Message Format", RFC 2440, November 1998. | "OpenPGP Message Format", RFC 2440, November 1998. | |||
[RFC3766] Orman, H. and P. Hoffman, "Determing Strengths for Public | [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths for | |||
Keys Used For Exchanging Symmetric Keys", RFC 3766, | Public Keys Used For Exchanging Symmetric Keys", RFC 3766, | |||
April 2004. | April 2004. | |||
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain | [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain | |||
Name System (DNS)", RFC 3833, August 2004. | Name System (DNS)", RFC 3833, August 2004. | |||
[RFC3851] Ramsdell, B., "S/MIME Version 3 Message Specification", | [RFC3851] Ramsdell, B., "S/MIME Version 3 Message Specification", | |||
RFC 3851, June 1999. | RFC 3851, June 1999. | |||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Rose, "DNS Security Introduction and Requirements", | Rose, "DNS Security Introduction and Requirements", | |||
skipping to change at page 52, line 5 | skipping to change at page 55, line 24 | |||
We lost the game. Are you hungry yet? | We lost the game. Are you hungry yet? | |||
Joe. | Joe. | |||
A.2 The email is signed | A.2 The email is signed | |||
This email is signed by the example.com outbound email server and now | This email is signed by the example.com outbound email server and now | |||
looks like this: | looks like this: | |||
DKIM-Signature: a=rsa-sha1; s=brisbane; d=example.com; | DKIM-Signature: a=rsa-sha256; s=brisbane; d=example.com; | |||
c=simple; q=dns/txt; i=joe@football.example.com; | c=simple; q=dns/txt; i=joe@football.example.com; | |||
h=Received : From : To : Subject : Date : Message-ID; | h=Received : From : To : Subject : Date : Message-ID; | |||
bh=ZSVEYuq4ri3LR9S+qjlzCP+LxvJrIfrOI2g5hxp5+MI=; | ||||
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ | b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ | |||
VoG4ZHRNiYzR; | VoG4ZHRNiYzR; | |||
Received: from dsl-10.2.3.4.football.example.com [10.2.3.4] | Received: from dsl-10.2.3.4.football.example.com [10.2.3.4] | |||
by submitserver.example.com with SUBMISSION; | by submitserver.example.com with SUBMISSION; | |||
Fri, 11 Jul 2003 21:01:54 -0700 (PDT) | Fri, 11 Jul 2003 21:01:54 -0700 (PDT) | |||
From: Joe SixPack <joe@football.example.com> | From: Joe SixPack <joe@football.example.com> | |||
To: Suzie Q <suzie@shopping.example.net> | To: Suzie Q <suzie@shopping.example.net> | |||
Subject: Is dinner ready? | Subject: Is dinner ready? | |||
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) | Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) | |||
Message-ID: <20030712040037.46341.5F8J@football.example.com> | Message-ID: <20030712040037.46341.5F8J@football.example.com> | |||
Hi. | Hi. | |||
We lost the game. Are you hungry yet? | We lost the game. Are you hungry yet? | |||
Joe. | Joe. | |||
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 the | query and subsequent verification of the signature is stored in the | |||
"Authentication-Results" header field line. After successful | "Authentication-Results" header field line. After successful | |||
verification, the email looks like this: | verification, the email looks like this: | |||
Authentication-Results: shopping.example.net | X-Authentication-Results: shopping.example.net | |||
header.from=joe@football.example.com; dkim=pass | header.from=joe@football.example.com; dkim=pass | |||
Received: from mout23.football.example.com (192.168.1.1) | Received: from mout23.football.example.com (192.168.1.1) | |||
by shopping.example.net with SMTP; | by shopping.example.net with SMTP; | |||
Fri, 11 Jul 2003 21:01:59 -0700 (PDT) | Fri, 11 Jul 2003 21:01:59 -0700 (PDT) | |||
DKIM-Signature: a=rsa-sha1; s=brisbane; d=example.com; | DKIM-Signature: a=rsa-sha256; s=brisbane; d=example.com; | |||
c=simple; q=dns/txt; i=joe@football.example.com; | c=simple; q=dns/txt; i=joe@football.example.com; | |||
h=Received : From : To : Subject : Date : Message-ID; | h=Received : From : To : Subject : Date : Message-ID; | |||
bh=ZSVEYuq4ri3LR9S+qjlzCP+LxvJrIfrOI2g5hxp5+MI=; | ||||
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ | b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ | |||
VoG4ZHRNiYzR | VoG4ZHRNiYzR | |||
Received: from dsl-10.2.3.4.network.example.com [10.2.3.4] | Received: from dsl-10.2.3.4.network.example.com [10.2.3.4] | |||
by submitserver.example.com with SUBMISSION; | by submitserver.example.com with SUBMISSION; | |||
Fri, 11 Jul 2003 21:01:54 -0700 (PDT) | Fri, 11 Jul 2003 21:01:54 -0700 (PDT) | |||
From: Joe SixPack <joe@football.example.com> | From: Joe SixPack <joe@football.example.com> | |||
To: Suzie Q <suzie@shopping.example.net> | To: Suzie Q <suzie@shopping.example.net> | |||
Subject: Is dinner ready? | Subject: Is dinner ready? | |||
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) | Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) | |||
Message-ID: <20030712040037.46341.5F8J@football.example.com> | Message-ID: <20030712040037.46341.5F8J@football.example.com> | |||
skipping to change at page 53, line 50 | skipping to change at page 57, line 25 | |||
.forward file or equivalent. In this case messages are typically | .forward file or equivalent. In this case messages are typically | |||
forwarded without modification, except for the addition of a Received | forwarded without modification, except for the addition of a Received | |||
header field to the message and a change in the Envelope-to address. | header field to the message and a change in the Envelope-to address. | |||
In this case, the eventual recipient should be able to verify the | In this case, the eventual recipient should be able to verify the | |||
original signature since the signed content has not changed, and | original signature since the signed content has not changed, and | |||
attribute the message correctly. | attribute the message correctly. | |||
B.2 Outsourced Business Functions | B.2 Outsourced Business Functions | |||
Outsourced business functions represent a use case that motivates the | Outsourced business functions represent a use case that motivates the | |||
need for selectors (the "s=" signature tag) and granularity (the "g=" | need for Selectors (the "s=" signature tag) and granularity (the "g=" | |||
key tag). Examples of outsourced business functions are legitimate | key tag). Examples of outsourced business functions are legitimate | |||
email marketing providers and corporate benefits providers. In | email marketing providers and corporate benefits providers. In | |||
either case, the outsourced function would like to be able to send | either case, the outsourced function would like to be able to send | |||
messages using the email domain of the client company. At the same | messages using the email domain of the client company. At the same | |||
time, the client may be reluctant to register a key for the provider | time, the client may be reluctant to register a key for the provider | |||
that grants the ability to send messages for any address in the | that grants the ability to send messages for any address in the | |||
domain. | domain. | |||
The outsourcing company can generate a keypair and the client company | The outsourcing company can generate a keypair and the client company | |||
can register the public key using a unique selector for a specific | can register the public key using a unique Selector for a specific | |||
address such as winter-promotions@example.com by specifying a | address such as winter-promotions@example.com by specifying a | |||
granularity of "g=winter-promotions" or "g=*-promotions" (to allow a | granularity of "g=winter-promotions" or "g=*-promotions" (to allow a | |||
range of addresses). This would enable the provider to send messages | range of addresses). This would enable the provider to send messages | |||
using that specific address and have them verify properly. The | using that specific address and have them verify properly. The | |||
client company retains control over the email address because it | client company retains control over the email address because it | |||
retains the ability to revoke the key at any time. | retains the ability to revoke the key at any time. | |||
B.3 PDAs and Similar Devices | B.3 PDAs and Similar Devices | |||
PDAs are one example of the use of multiple keys per user. Suppose | PDAs are one example of the use of multiple keys per user. Suppose | |||
skipping to change at page 56, line 7 | skipping to change at page 59, line 29 | |||
One way this can be handled is to continue to put the reader's email | One way this can be handled is to continue to put the reader's email | |||
address in the From header field of the message, but put an address | address in the From header field of the message, but put an address | |||
owned by the site into the Sender header field, and sign the message | owned by the site into the Sender header field, and sign the message | |||
on behalf of that address. A verifying MTA could accept this and | on behalf of that address. A verifying MTA could accept this and | |||
rewrite the From header field to indicate the address that was | rewrite the From header field to indicate the address that was | |||
verified, i.e., From: John Doe via news@news-site.com | verified, i.e., From: John Doe via news@news-site.com | |||
<jdoe@example.com>. (However, such rewriting must be done after the | <jdoe@example.com>. (However, such rewriting must be done after the | |||
verification pass is complete, and will break any later attempts to | verification pass is complete, and will break any later attempts to | |||
re-verify.) | re-verify.) | |||
B.7 SMTP Servers for Roaming Users | ||||
Roaming users may find themselves in circumstances where it is | ||||
convenient or necessary to use an SMTP server other than their home | ||||
server; examples are IETF conferences and many hotels. In such | ||||
circumstances the signature, if any, will be added by a party other | ||||
than the user's home system. | ||||
Ideally roaming users would connect back to their home server using | ||||
either a VPN or a SUBMISSION server running with SMTP AUTHentication | ||||
on port 587. If the signing can be performed on the roaming user's | ||||
laptop then they can sign before submission, although the risk of | ||||
further modification may be high. If neither of these are possible, | ||||
these roaming users will not be able to send mail signed using their | ||||
own domain key. | ||||
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 768 bit private-key suitable for DKIM, is to use | way to generate a 1024 bit, unencrypted private-key suitable for | |||
openssl like this: | DKIM, is to use openssl like this: | |||
$ openssl genrsa -out rsa.private 1024 | $ openssl genrsa -out rsa.private 1024 | |||
This results in the file rsa.private containing the key information | For increased security, the "-passin" parameter can also be added to | |||
similar to this: | encrypt the private key. Use of this parameter will require entering | |||
a password for several of the following steps. Servers may prefer to | ||||
use hardware cryptographic support. | ||||
The "genrsa" step results in the file rsa.private containing the key | ||||
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/ | |||
skipping to change at page 57, line 34 | skipping to change at page 61, line 23 | |||
This results in signature data similar to this when represented in | This results in signature data similar to this when represented in | |||
Base64 [MIME] format: | Base64 [MIME] format: | |||
aoiDeX42BB/gP4ScqTdIQJcpAObYr+54yvctqc4rSEFYby9+omKD3pJ/TVxATeTz | aoiDeX42BB/gP4ScqTdIQJcpAObYr+54yvctqc4rSEFYby9+omKD3pJ/TVxATeTz | |||
msybuW3WZiamb+mvn7f3rhmnozHJ0yORQbnn4qJQhPbbPbWEQKW09AMJbyz/0lsl | msybuW3WZiamb+mvn7f3rhmnozHJ0yORQbnn4qJQhPbbPbWEQKW09AMJbyz/0lsl | |||
How this signature is added to the email is discussed elsewhere in | How this signature is added to the email is discussed elsewhere in | |||
this document. | this document. | |||
The final record entered into a DNS zone file would be: | ||||
brisbane IN TXT ("v=DKIM1; p=aoiDeX42BB/gP4ScqTdIQJcpAObYr+54yvct" | ||||
"qc4rSEFYby9+omKD3pJ/TVxATeTzmsybuW3WZiamb+mvn7f" | ||||
"3rhmnozHJ0yORQbnn4qJQhPbbPbWEQKW09AMJbyz/0lsl" ) | ||||
Appendix D. MUA Considerations | Appendix D. MUA Considerations | |||
When a DKIM signature is verified, one of the results is a validated | When a DKIM signature is verified, one of the results is a validated | |||
signing identity. MUAs might highlight the address associated with | signing identity. MUAs might highlight the address associated with | |||
this identity in some way to show the user the address from which the | this identity in some way to show the user the address from which the | |||
mail is sent. An MUA might do this with visual cues such as | mail is sent. An MUA might do this with visual cues such as | |||
graphics, or it might include the address in an alternate views, or | graphics, or it might include the address in an alternate views, or | |||
it might even rewrite the original "From:" address using the verified | it might even rewrite the original "From:" address using the verified | |||
information. Some MUAs might want to indicate which headers were | information. Some MUAs might want to indicate which headers were | |||
covered in a validated DKIM signature. This might be done with a | covered in a validated DKIM signature. This might be done with a | |||
skipping to change at page 58, line 36 | skipping to change at page 62, line 35 | |||
The DomainKeys specification was a primary source from which this | The DomainKeys specification was a primary source from which this | |||
specification has been derived. Further information about DomainKeys | specification has been derived. Further information about DomainKeys | |||
is at | is at | |||
<http://domainkeys.sourceforge.net/license/patentlicense1-1.html>. | <http://domainkeys.sourceforge.net/license/patentlicense1-1.html>. | |||
Appendix F. Edit History | Appendix F. Edit History | |||
[[This section to be removed before publication.]] | [[This section to be removed before publication.]] | |||
F.1 Changes since -ietf-02 version | F.1 Changes since -ietf-03 version | |||
The following changes were made between draft-ietf-dkim-base-03 and | ||||
draft-ietf-dkim-base-04: | ||||
o Re-worded Abstract to avoid use of "prove" and "non-repudiation". | ||||
o Use dot-atom-text instead of dot-atom to avoid inclusion of CFWS. | ||||
o Capitalize Selector throughout. | ||||
o Add discussion of plain text, mentioning informatively that | ||||
implementors should plan for eventual 8-bit requirements. | ||||
o Drop RSA requirement of exponent of 65537 (not required, since it | ||||
is already in the key) and clarify the key format. | ||||
o Drop SHOULD that DKIM-Signature should precede header fields that | ||||
it signs. | ||||
o Mention that wildcard DNS records MUST NOT be used for selector | ||||
records. | ||||
o Add section 3.8 to clarify the t=s flag. | ||||
o Change the list of header fields that MUST be signed to include | ||||
only From. | ||||
o Require that verifier check that From is in the list of signed | ||||
header fields. | ||||
o Drop all reference to draft-kucherawy-sender-auth-header draft. | ||||
o Substantially expand Section 7 (IANA Considerations) to include | ||||
initial registries. | ||||
o Add section B.7 (use case: SMTP Servers for Roaming Users). | ||||
o Add several examples; update some others. | ||||
o Considerable minor editorial updating to clarify language, delete | ||||
redundant text, fix spelling errors, etc. | ||||
Still to be resolved: | ||||
o How does "simple" body canonicalization interact with BINARYMIME | ||||
data? | ||||
o Deal with "relaxed" body canonicalizations, especially in regard | ||||
to bare CRs and NLs. | ||||
o How to handle "*" in g= dot-atom-text (which allows "*" as a | ||||
literal character). | ||||
o The IANA Considerations need to be completed and cleaned up. | ||||
F.2 Changes since -ietf-02 version | ||||
The following changes were made between draft-ietf-dkim-base-02 and | The following changes were made between draft-ietf-dkim-base-02 and | |||
draft-ietf-dkim-base-03: | draft-ietf-dkim-base-03: | |||
o Section 5.2: changed key expiration text to be informational; | o Section 5.2: changed key expiration text to be informational; | |||
drop "seven day" wording in favor of something vaguer. | drop "seven day" wording in favor of something vaguer. | |||
o Don't indicate that the "i=" tag value should be passed to the key | o Don't indicate that the "i=" tag value should be passed to the key | |||
lookup service; this can be added as an extension if required. | lookup service; this can be added as an extension if required. | |||
skipping to change at page 59, line 36 | skipping to change at page 64, line 45 | |||
may contain the content. | may contain the content. | |||
o Use dkim-quoted-printable as the encoding used in z= rather than | o Use dkim-quoted-printable as the encoding used in z= rather than | |||
referring to RFC2045, since they are different. | referring to RFC2045, since they are different. | |||
o Rewrite description of g= tag in the key record. | o Rewrite description of g= tag in the key record. | |||
o Deleted use of Domain in ABNF, which permits address-literals; | o Deleted use of Domain in ABNF, which permits address-literals; | |||
define domain-name to act in stead. | define domain-name to act in stead. | |||
F.2 Changes since -ietf-01 version | F.3 Changes since -ietf-01 version | |||
The following changes were made between draft-ietf-dkim-base-01 and | The following changes were made between draft-ietf-dkim-base-01 and | |||
draft-ietf-dkim-base-02: | draft-ietf-dkim-base-02: | |||
o Change wording on "x=" tag in DKIM-Signature header field | o Change wording on "x=" tag in DKIM-Signature header field | |||
regarding verifier handling of expired signatures from MUST to MAY | regarding verifier handling of expired signatures from MUST to MAY | |||
(per 20 April Jabber session). Also, make it clear that received | (per 20 April Jabber session). Also, make it clear that received | |||
time is to be preferred over current time if reliably available. | time is to be preferred over current time if reliably available. | |||
o Several changes to limit wording that would intrude into verifier | o Several changes to limit wording that would intrude into verifier | |||
skipping to change at page 60, line 21 | skipping to change at page 65, line 28 | |||
o Change "q=dns" query access method to "q=dnstxt" to emphasize the | o Change "q=dns" query access method to "q=dnstxt" to emphasize the | |||
use of the TXT record. The expectation is that a later extension | use of the TXT record. The expectation is that a later extension | |||
will define "q=dnsdkk" to indicate use of a DKK record. (Per 18 | will define "q=dnsdkk" to indicate use of a DKK record. (Per 18 | |||
May Jabber session.) | May Jabber session.) | |||
o Several typos fixed, including removing a paragraph that implied | o Several typos fixed, including removing a paragraph that implied | |||
that the DKIM-Signature header field should be hashed with the | that the DKIM-Signature header field should be hashed with the | |||
body (it should not). | body (it should not). | |||
F.3 Changes since -ietf-00 version | F.4 Changes since -ietf-00 version | |||
The following changes were made between draft-ietf-dkim-base-00 and | The following changes were made between draft-ietf-dkim-base-00 and | |||
draft-ietf-dkim-base-01: | draft-ietf-dkim-base-01: | |||
o Added section 8.9 (Information Leakage). | o Added section 8.9 (Information Leakage). | |||
o Replace section 4 (Multiple Signatures) with much less vague text. | o Replace section 4 (Multiple Signatures) with much less vague text. | |||
o Fixed ABNF for base64string. | o Fixed ABNF for base64string. | |||
skipping to change at page 60, line 45 | skipping to change at page 66, line 7 | |||
o Changed signing algorithm to use separate hash of the body of the | o Changed signing algorithm to use separate hash of the body of the | |||
message; this is represented as the "bh=" tag in the DKIM- | message; this is represented as the "bh=" tag in the DKIM- | |||
Signature header field. | Signature header field. | |||
o Changed "z=" tag so that it need not have the same header field | o Changed "z=" tag so that it need not have the same header field | |||
names as the "h=" tag. | names as the "h=" tag. | |||
o Significant wordsmithing. | o Significant wordsmithing. | |||
F.4 Changes since -allman-01 version | F.5 Changes since -allman-01 version | |||
The following changes were made between draft-allman-dkim-base-01 and | The following changes were made between draft-allman-dkim-base-01 and | |||
draft-ietf-dkim-base-00: | draft-ietf-dkim-base-00: | |||
o Remove references to Sender Signing Policy document. Such | o Remove references to Sender Signing Policy document. Such | |||
consideration is implicitly included in Section 6.3. | consideration is implicitly included in Section 6.3. | |||
o Added ABNF for all tags. | o Added ABNF for all tags. | |||
o Updated references (still includes some references to expired | o Updated references (still includes some references to expired | |||
drafts, notably [ID-AUTH-RES]. | drafts, notably ID-AUTH-RES. | |||
o Significant wordsmithing. | o Significant wordsmithing. | |||
F.5 Changes since -allman-00 version | F.6 Changes since -allman-00 version | |||
The following changes were made between draft-allman-dkim-base-00 and | The following changes were made between draft-allman-dkim-base-00 and | |||
draft-allman-dkim-base-01: | draft-allman-dkim-base-01: | |||
o Changed "c=" tag to separate out header from body | o Changed "c=" tag to separate out header from body | |||
canonicalization. | canonicalization. | |||
o Eliminated "nowsp" canonicalization in favor of "relaxed", which | o Eliminated "nowsp" canonicalization in favor of "relaxed", which | |||
is somewhat less relaxed (but more secure) than "nowsp". | is somewhat less relaxed (but more secure) than "nowsp". | |||
End of changes. 151 change blocks. | ||||
454 lines changed or deleted | 707 lines changed or added | |||
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |