draft-ietf-dkim-base-05.txt | draft-ietf-dkim-base-06.txt | |||
---|---|---|---|---|
DKIM E. Allman | DKIM E. Allman | |||
Internet-Draft Sendmail, Inc. | Internet-Draft Sendmail, Inc. | |||
Expires: February 24, 2007 J. Callas | Expires: April 23, 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. | |||
August 23, 2006 | October 20, 2006 | |||
DomainKeys Identified Mail (DKIM) Signatures | DomainKeys Identified Mail (DKIM) Signatures | |||
draft-ietf-dkim-base-05 | draft-ietf-dkim-base-06 | |||
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 February 24, 2007. | This Internet-Draft will expire on April 23, 2007. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
Abstract | Abstract | |||
DomainKeys Identified Mail (DKIM) defines a domain-level | DomainKeys Identified Mail (DKIM) defines a domain-level | |||
authentication framework for email using public-key cryptography and | authentication framework for email using public-key cryptography and | |||
key server technology to permit verification of the source and | key server technology to permit verification of the source and | |||
skipping to change at page 3, line 12 | skipping to change at page 3, line 12 | |||
"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 Signing Identity . . . . . . . . . . . . . . . . . . . . . 6 | 1.1 Signing Identity . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 | 1.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.3 Simple Key Management . . . . . . . . . . . . . . . . . . 6 | 1.3 Simple Key Management . . . . . . . . . . . . . . . . . . 6 | |||
2. Terminology and Definitions . . . . . . . . . . . . . . . . 6 | 2. Terminology and Definitions . . . . . . . . . . . . . . . . 6 | |||
2.1 Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.1 Signers . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.2 Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.2 Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.3 White Space . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.3 White Space . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.4 Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 7 | 2.4 Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 7 | |||
2.5 Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 7 | 2.5 Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 8 | |||
2.6 DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 8 | 2.6 DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 8 | |||
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . 9 | 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.1 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 9 | 3.1 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
3.2 Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 11 | 3.2 Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 11 | |||
3.3 Signing and Verification Algorithms . . . . . . . . . . . 12 | 3.3 Signing and Verification Algorithms . . . . . . . . . . . 12 | |||
3.4 Canonicalization . . . . . . . . . . . . . . . . . . . . . 14 | 3.4 Canonicalization . . . . . . . . . . . . . . . . . . . . . 14 | |||
3.5 The DKIM-Signature header field . . . . . . . . . . . . . 18 | 3.5 The DKIM-Signature header field . . . . . . . . . . . . . 18 | |||
3.6 Key Management and Representation . . . . . . . . . . . . 26 | 3.6 Key Management and Representation . . . . . . . . . . . . 25 | |||
3.7 Computing the Message Hashes . . . . . . . . . . . . . . . 30 | 3.7 Computing the Message Hashes . . . . . . . . . . . . . . . 29 | |||
3.8 Signing by Parent Domains . . . . . . . . . . . . . . . . 32 | 3.8 Signing by Parent Domains . . . . . . . . . . . . . . . . 31 | |||
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . 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 . . . 33 | 5.1 Determine if the Email Should be Signed and by Whom . . . 32 | |||
5.2 Select a private-key and corresponding selector | 5.2 Select a private-key and corresponding selector | |||
information . . . . . . . . . . . . . . . . . . . . . . . 33 | information . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
5.3 Normalize the Message to Prevent Transport Conversions . . 34 | 5.3 Normalize the Message to Prevent Transport Conversions . . 33 | |||
5.4 Determine the header fields to Sign . . . . . . . . . . . 34 | 5.4 Determine the header fields to Sign . . . . . . . . . . . 34 | |||
5.5 Compute the Message Hash and Signature . . . . . . . . . . 36 | 5.5 Compute the Message Hash and Signature . . . . . . . . . . 36 | |||
5.6 Insert the DKIM-Signature header field . . . . . . . . . . 37 | 5.6 Insert the DKIM-Signature header field . . . . . . . . . . 36 | |||
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 37 | 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 37 | |||
6.1 Extract Signatures from the Message . . . . . . . . . . . 38 | 6.1 Extract Signatures from the Message . . . . . . . . . . . 37 | |||
6.2 Communicate Verification Results . . . . . . . . . . . . . 43 | 6.2 Communicate Verification Results . . . . . . . . . . . . . 42 | |||
6.3 Interpret Results/Apply Local Policy . . . . . . . . . . . 43 | 6.3 Interpret Results/Apply Local Policy . . . . . . . . . . . 43 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 45 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 44 | |||
7.1 DKIM-Signature Tag Specifications . . . . . . . . . . . . 45 | 7.1 DKIM-Signature Tag Specifications . . . . . . . . . . . . 44 | |||
7.2 DKIM-Signature Query Method Registry . . . . . . . . . . . 45 | 7.2 DKIM-Signature Query Method Registry . . . . . . . . . . . 45 | |||
7.3 DKIM-Signature Canonicalization Registry . . . . . . . . . 46 | 7.3 DKIM-Signature Canonicalization Registry . . . . . . . . . 45 | |||
7.4 _domainkey DNS TXT Record Tag Specifications . . . . . . . 46 | 7.4 _domainkey DNS TXT Record Tag Specifications . . . . . . . 46 | |||
7.5 DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 47 | 7.5 DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 47 | |||
7.6 DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 47 | 7.6 DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 47 | |||
7.7 DKIM Service Types Registry . . . . . . . . . . . . . . . 48 | 7.7 DKIM Service Types Registry . . . . . . . . . . . . . . . 47 | |||
7.8 DKIM Selector Flags Registry . . . . . . . . . . . . . . . 48 | 7.8 DKIM Selector Flags Registry . . . . . . . . . . . . . . . 48 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . 49 | 8. Security Considerations . . . . . . . . . . . . . . . . . . 48 | |||
8.1 Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 49 | 8.1 Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 48 | |||
8.2 Misappropriated Private Key . . . . . . . . . . . . . . . 49 | 8.2 Misappropriated Private Key . . . . . . . . . . . . . . . 49 | |||
8.3 Key Server Denial-of-Service Attacks . . . . . . . . . . . 50 | 8.3 Key Server Denial-of-Service Attacks . . . . . . . . . . . 50 | |||
8.4 Attacks Against DNS . . . . . . . . . . . . . . . . . . . 51 | 8.4 Attacks Against DNS . . . . . . . . . . . . . . . . . . . 50 | |||
8.5 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 51 | 8.5 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 51 | |||
8.6 Limits on Revoking Keys . . . . . . . . . . . . . . . . . 52 | 8.6 Limits on Revoking Keys . . . . . . . . . . . . . . . . . 51 | |||
8.7 Intentionally malformed Key Records . . . . . . . . . . . 52 | 8.7 Intentionally malformed Key Records . . . . . . . . . . . 52 | |||
8.8 Intentionally Malformed DKIM-Signature header fields . . . 52 | 8.8 Intentionally Malformed DKIM-Signature header fields . . . 52 | |||
8.9 Information Leakage . . . . . . . . . . . . . . . . . . . 52 | 8.9 Information Leakage . . . . . . . . . . . . . . . . . . . 52 | |||
8.10 Remote Timing Attacks . . . . . . . . . . . . . . . . . 53 | 8.10 Remote Timing Attacks . . . . . . . . . . . . . . . . . 52 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 | |||
9.1 Normative References . . . . . . . . . . . . . . . . . . . 53 | 9.1 Normative References . . . . . . . . . . . . . . . . . . . 52 | |||
9.2 Informative References . . . . . . . . . . . . . . . . . . 53 | 9.2 Informative References . . . . . . . . . . . . . . . . . . 53 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 54 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 54 | |||
A. Example of Use (INFORMATIVE) . . . . . . . . . . . . . . . . 56 | A. Example of Use (INFORMATIVE) . . . . . . . . . . . . . . . . 55 | |||
A.1 The user composes an email . . . . . . . . . . . . . . . . 56 | A.1 The user composes an email . . . . . . . . . . . . . . . . 55 | |||
A.2 The email is signed . . . . . . . . . . . . . . . . . . . 56 | A.2 The email is signed . . . . . . . . . . . . . . . . . . . 56 | |||
A.3 The email signature is verified . . . . . . . . . . . . . 57 | A.3 The email signature is verified . . . . . . . . . . . . . 56 | |||
B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . . . . . 58 | B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . . . . . 57 | |||
B.1 Simple Message Forwarding . . . . . . . . . . . . . . . . 58 | B.1 Alternate Submission Scenarios . . . . . . . . . . . . . . 58 | |||
B.2 Outsourced Business Functions . . . . . . . . . . . . . . 58 | B.2 Alternate Delivery Scenarios . . . . . . . . . . . . . . . 60 | |||
B.3 PDAs and Similar Devices . . . . . . . . . . . . . . . . . 59 | C. Creating a public key (INFORMATIVE) . . . . . . . . . . . . 62 | |||
B.4 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 59 | D. MUA Considerations . . . . . . . . . . . . . . . . . . . . . 64 | |||
B.5 Affinity Addresses . . . . . . . . . . . . . . . . . . . . 60 | E. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65 | |||
B.6 Third-party Message Transmission . . . . . . . . . . . . . 60 | F. Edit History . . . . . . . . . . . . . . . . . . . . . . . . 65 | |||
B.7 SMTP Servers for Roaming Users . . . . . . . . . . . . . . 61 | F.1 Changes since -ietf-05 version . . . . . . . . . . . . . . 65 | |||
C. Creating a public key (INFORMATIVE) . . . . . . . . . . . . 61 | F.2 Changes since -ietf-04 version . . . . . . . . . . . . . . 66 | |||
D. MUA Considerations . . . . . . . . . . . . . . . . . . . . . 63 | F.3 Changes since -ietf-03 version . . . . . . . . . . . . . . 66 | |||
E. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 63 | F.4 Changes since -ietf-02 version . . . . . . . . . . . . . . 67 | |||
F. Edit History . . . . . . . . . . . . . . . . . . . . . . . . 64 | F.5 Changes since -ietf-01 version . . . . . . . . . . . . . . 68 | |||
F.1 Changes since -ietf-04 version . . . . . . . . . . . . . . 64 | F.6 Changes since -ietf-00 version . . . . . . . . . . . . . . 69 | |||
F.2 Changes since -ietf-03 version . . . . . . . . . . . . . . 64 | F.7 Changes since -allman-01 version . . . . . . . . . . . . . 69 | |||
F.3 Changes since -ietf-02 version . . . . . . . . . . . . . . 66 | F.8 Changes since -allman-00 version . . . . . . . . . . . . . 70 | |||
F.4 Changes since -ietf-01 version . . . . . . . . . . . . . . 67 | Intellectual Property and Copyright Statements . . . . . . . 71 | |||
F.5 Changes since -ietf-00 version . . . . . . . . . . . . . . 67 | ||||
F.6 Changes since -allman-01 version . . . . . . . . . . . . . 68 | ||||
F.7 Changes since -allman-00 version . . . . . . . . . . . . . 68 | ||||
Intellectual Property and Copyright Statements . . . . . . . 69 | ||||
1. Introduction | 1. Introduction | |||
[[Note: text in double square brackets (such as this text) will be | [[Note: text in double square brackets (such as this text) will be | |||
deleted before publication.]] | deleted before publication.]] | |||
DomainKeys Identified Mail (DKIM) defines a mechanism by which email | DomainKeys Identified Mail (DKIM) defines a mechanism by which email | |||
messages can be cryptographically signed, permitting a signing domain | messages can be cryptographically signed, permitting a signing domain | |||
to claim responsibility for the introduction of a message into the | to claim responsibility for the introduction of a message into the | |||
mail stream. Message recipients can verify the signature by querying | mail stream. Message recipients can verify the signature by querying | |||
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: | |||
o the message signature is written as a message header field so that | o the message signature is written as a message header field so that | |||
neither human recipients nor existing MUA (Mail User Agent) | neither human recipients nor existing MUA (Mail User Agent) | |||
software are confused by signature-related content appearing in | software are confused by signature-related content appearing in | |||
the message body, | the message body; | |||
o there is no dependency on public and private key pairs being | o there is no dependency on public and private key pairs being | |||
issued by well-known, trusted certificate authorities, | issued by well-known, trusted certificate authorities; | |||
o there is no dependency on the deployment of any new Internet | o there is no dependency on the deployment of any new Internet | |||
protocols or services for public key distribution or revocation, | protocols or services for public key distribution or revocation; | |||
o signature verification failure does not result in rejection of the | o signature verification failure does not result in rejection of the | |||
message, | message; | |||
o no attempt is made to include encryption as part of the mechanism, | o no attempt is made to include encryption as part of the mechanism; | |||
o archival is not a design goal. | o 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 an additional trusted third party | o does not require the use of an additional trusted third party | |||
(such as a certificate authority or other entity) which might | (such as a certificate authority or other entity) which might | |||
impose 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 allows delegation of signing to third parties. | |||
1.1 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. | |||
skipping to change at page 6, line 34 | skipping to change at page 6, line 34 | |||
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.3 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 Certificate Authority infrastructure is required; the verifier | |||
public key from the claimed signer directly. | requests the public key from a repository in the domain of the | |||
claimed signer directly rather than from a third party. | ||||
The DNS is proposed as the initial mechanism for publishing public | The DNS is proposed as the initial mechanism for the public keys. | |||
keys. DKIM is designed to be extensible to other key fetching | Thus, DKIM currently depends on DNS adminstration and the security of | |||
services as they become available. | the DNS system. DKIM is designed to be extensible to other key | |||
fetching services as they become available. | ||||
2. Terminology and Definitions | 2. Terminology and Definitions | |||
This section defines terms used in the rest of the document. Syntax | This section defines terms used in the rest of the document. Syntax | |||
descriptions use the form described in Augmented BNF for Syntax | descriptions use the form described in Augmented BNF for Syntax | |||
Specifications [RFC4234]. | Specifications [RFC4234]. | |||
2.1 Signers | 2.1 Signers | |||
Elements in the mail system that sign messages are referred to as | Elements in the mail system that sign messages are referred to as | |||
skipping to change at page 7, line 24 | skipping to change at page 7, line 28 | |||
verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs. | verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs. | |||
In most cases it is expected that verifiers will be close to an end | In most cases it is expected that verifiers will be close to an end | |||
user (reader) of the message or some consuming agent such as a | user (reader) of the message or some consuming agent such as a | |||
mailing list exploder. | mailing list exploder. | |||
2.3 White Space | 2.3 White Space | |||
There are three forms of white space: | There are three forms of white space: | |||
o WSP represents simple white space, i.e., a space or a tab | o WSP represents simple white space, i.e., a space or a tab | |||
character. | character (formal definition in [RFC4234]). | |||
o SWSP is streaming white space, defined as WSP plus CRLF. | o LWSP is linear white space, defined as WSP plus CRLF (formal | |||
definition in [RFC4234]). | ||||
o FWS is folding white space. It allows multiple lines separated by | o FWS is folding white space. It allows multiple lines separated by | |||
CRLF followed by at least one white space, to be joined. | CRLF followed by at least one white space, to be joined. | |||
The formal ABNF SWSP and FWS is: | The formal ABNF for these are (WSP and LWSP are given for information | |||
only): | ||||
SWSP = WSP / CRLF ; streaming white space | WSP = SP / HTAB | |||
FWSP = ([*WSP CRLF] 1*WSP) | LWSP = *(WSP / CRLF WSP) | |||
FWS = [*WSP CRLF] 1*WSP | ||||
The definition of FWS is identical to that in [RFC2822] except for | The definition of FWS is identical to that in [RFC2822] except for | |||
the exclusion of obs-FWS. WSP is inherited from [RFC4234]. | the exclusion of obs-FWS. | |||
2.4 Common ABNF Tokens | 2.4 Common ABNF Tokens | |||
The following ABNF tokens are used elsewhere in this document. | The following ABNF tokens are used elsewhere in this document. | |||
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] | hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] | |||
base64string = 1*(ALPHA / DIGIT / "+" / "/" / "=" / SWSP) | base64string = 1*(ALPHA / DIGIT / "+" / "/" / LWSP) | |||
[ "=" *LWSP [ "=" *LWSP ] ] | ||||
2.5 Imported ABNF Tokens | 2.5 Imported ABNF Tokens | |||
The following tokens are imported from other RFCs as noted. Those | The following tokens are imported from other RFCs as noted. Those | |||
RFCs should be considered definitive. However, all tokens having | RFCs should be considered definitive. However, all tokens having | |||
names beginning with "obs-" should be excluded from this import, as | names beginning with "obs-" should be excluded from this import, as | |||
they have been obsoleted and are expected to go away in future | they have been obsoleted and are expected to go away in future | |||
editions of those RFCs. | editions of those RFCs. | |||
The following tokens are imported from [RFC2821]: | The following tokens are imported from [RFC2821]: | |||
o "Local-part" (implementation warning: this permits quoted | o "Local-part" (implementation warning: this permits quoted | |||
strings) | strings) | |||
o "sub-domain" | o "sub-domain" | |||
The following definitions are imported from [RFC2822]: | The following definitions are imported from [RFC2822]: | |||
o "WSP" (space or tab) | ||||
o "FWS" (folding white space) | ||||
o "field-name" (name of a header field) | o "field-name" (name of a header field) | |||
o "dot-atom-text" (in the local-part of an email address) | o "dot-atom-text" (in the local-part of an email address) | |||
The following tokens are imported from [RFC2045]: | The following tokens are imported from [RFC2045]: | |||
o "qp-section" (a single line of quoted-printable-encoded text) | o "qp-section" (a single line of quoted-printable-encoded text) | |||
o "hex-octet" (a quoted-printable encoded octet) | o "hex-octet" (a quoted-printable encoded octet) | |||
skipping to change at page 11, line 16 | skipping to change at page 11, line 19 | |||
The distinction between revoking and removing a key selector | The distinction between revoking and removing a key selector | |||
record is subtle. When phasing out keys as described above, a | record is subtle. When phasing out keys as described above, a | |||
signing domain would probably simply remove the key record after | signing domain would probably simply remove the key record after | |||
the transition period. However, a signing domain could elect to | the transition period. However, a signing domain could elect to | |||
revoke the key (but maintain the key record) for a further period. | revoke the key (but maintain the key record) for a further period. | |||
There is no defined semantic difference between a revoked key and | There is no defined semantic difference between a revoked key and | |||
a removed key. | a removed key. | |||
While some domains may wish to make Selector values well known, | 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 | 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. For example, if | |||
keys are issued, the domain owner will need to make the decision as | per-user keys are issued, the domain owner will need to make the | |||
to whether to associate this Selector directly with the user name, or | decision as to whether to associate this Selector directly with the | |||
make it some unassociated random value, such as a fingerprint of the | user name, or make it some unassociated random value, such as a | |||
public key. | fingerprint of the public key. | |||
INFORMATIVE IMPLEMENTERS' NOTE: reusing a Selector with a new key | Reusing a Selector with a new key (for example, changing the key | |||
(for example, changing the key associated with a user's name) | associated with a user's name) makes it impossible to tell the | |||
makes it impossible to tell the difference between a message that | difference between a message that didn't verify because the key is no | |||
didn't verify because the key is no longer valid versus a message | longer valid versus a message that is actually forged. Signers | |||
that is actually forged. Signers should not change the key | SHOULD NOT change the key associated with a Selector. When creating | |||
associated with a Selector. When creating a new key, signers | 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 | section 6.7), or "dkim-quoted-printable" (as defined in Section 2.6). | |||
name of the tag will determine the encoding of each value; however, | The name of the tag will determine the encoding of each value; | |||
no encoding may include the semicolon (";") character, since that | however, no encoding may include the semicolon (";") character, since | |||
separates tag-specs. | that separates tag-specs. | |||
INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" | INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" | |||
defined below (as "tag-value") only includes 7-bit characters, an | defined below (as "tag-value") only includes 7-bit characters, an | |||
implementation that wished to anticipate future standards would be | implementation that wished to anticipate future standards would be | |||
advised to not preclude the use of UTF8-encoded text in tag=value | advised to not preclude the use of UTF8-encoded text in tag=value | |||
lists. | lists. | |||
Formally, the syntax rules are: | Formally, the syntax rules are: | |||
tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] | tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] | |||
tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] | tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] | |||
tag-name = ALPHA 0*ALNUMPUNC | tag-name = ALPHA 0*ALNUMPUNC | |||
tag-value = [ 1*VALCHAR 0*( 1*(WSP / FWS) 1*VALCHAR ) ] | tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ] | |||
; WSP and FWS prohibited at beginning and end | ; WSP and FWS prohibited at beginning and end | |||
tval = 1*VALCHAR | ||||
VALCHAR = %x21-3A / %x3C-7E | VALCHAR = %x21-3A / %x3C-7E | |||
; EXCLAMATION to TILDE except SEMICOLON | ; EXCLAMATION to TILDE except SEMICOLON | |||
ALNUMPUNC = ALPHA / DIGIT / "_" | ALNUMPUNC = ALPHA / DIGIT / "_" | |||
Note that WSP is allowed anywhere around tags; in particular, any WSP | Note that WSP is allowed anywhere around tags; in particular, any WSP | |||
after the "=" and any WSP before the terminating ";" is not part of | after the "=" and any WSP before the terminating ";" is not part of | |||
the value; however, WSP inside the value is significant. | the value; however, WSP inside the value is significant. | |||
Tags MUST be interpreted in a case-sensitive manner. Values MUST be | Tags MUST be interpreted in a case-sensitive manner. Values MUST be | |||
processed as case sensitive unless the specific tag description of | processed as case sensitive unless the specific tag description of | |||
skipping to change at page 12, line 51 | skipping to change at page 12, line 52 | |||
DKIM supports multiple digital signature algorithms. Two algorithms | DKIM supports multiple digital signature algorithms. Two algorithms | |||
are defined by this specification at this time: rsa-sha1, and rsa- | are defined by this specification at this time: rsa-sha1, and rsa- | |||
sha256. The rsa-sha256 algorithm is the default if no algorithm is | sha256. The rsa-sha256 algorithm is the default if no algorithm is | |||
specified. Verifiers MUST implement both rsa-sha1 and rsa-sha256. | specified. Verifiers MUST implement both rsa-sha1 and rsa-sha256. | |||
Signers MUST implement and SHOULD sign using rsa-sha256. | Signers MUST implement and SHOULD sign using rsa-sha256. | |||
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 [SHA] as the hash-alg. That hash is | |||
signed by the signer using the RSA algorithm (defined in PKCS#1 | then signed by the signer using the RSA algorithm (defined in PKCS#1 | |||
version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. | version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. | |||
The hash MUST NOT be truncated or converted into any form other than | The hash MUST NOT be truncated or converted into any form other than | |||
the native binary form before being signed. | the native binary form before being signed. | |||
INFORMATIVE IMPLEMENTATION WARNING: Low-valued exponents should | ||||
be avoided, as they are believed to be subject to attack. | ||||
3.3.2 The rsa-sha256 Signing Algorithm | 3.3.2 The rsa-sha256 Signing Algorithm | |||
The rsa-sha256 Signing Algorithm computes a message hash as described | The rsa-sha256 Signing Algorithm computes a message hash as described | |||
in Section 3.7 below using SHA-256 as the hash-alg. That hash is | in Section 3.7 below using SHA-256 [SHA] as the hash-alg. That hash | |||
then signed by the signer using the RSA algorithm (actually PKCS#1 | is then signed by the signer using the RSA algorithm (actually PKCS#1 | |||
version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. | version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. | |||
The hash MUST NOT be truncated or converted into any form other than | The hash MUST NOT be truncated or converted into any form other than | |||
the native binary form before being signed. | the native binary form before being signed. | |||
3.3.3 Other algorithms | 3.3.3 Key sizes | |||
Other algorithms MAY be defined in the future. Verifiers MUST ignore | ||||
any signatures using algorithms that they do not implement. | ||||
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. Verifier policies may use the | validate signatures with larger keys. Verifier policies may use the | |||
length of the signing key as one metric for determining whether a | length of the signing key as one metric for determining whether a | |||
signature is acceptable. | signature is acceptable. | |||
skipping to change at page 13, line 47 | skipping to change at page 13, line 46 | |||
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 other systems that employ digital signatures | |||
See [RFC3766] for further discussion of selecting key sizes. | See [RFC3766] for further discussion of selecting key sizes. | |||
3.3.4 Other algorithms | ||||
Other algorithms MAY be defined in the future. Verifiers MUST ignore | ||||
any signatures using algorithms that they do not implement. | ||||
3.4 Canonicalization | 3.4 Canonicalization | |||
Empirical evidence demonstrates that some mail servers and relay | Empirical evidence demonstrates that some mail servers and relay | |||
systems modify email in transit, potentially invalidating a | systems modify email in transit, potentially invalidating a | |||
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. | |||
skipping to change at page 14, line 37 | skipping to change at page 14, line 42 | |||
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. Note that the header and body may use | canonicalization algorithms. Note that the header and body may use | |||
different canonicalization algorithms. Further canonicalization | different canonicalization algorithms. Further canonicalization | |||
algorithms MAY be defined in the future; verifiers MUST ignore any | algorithms MAY be defined in the future; verifiers MUST ignore any | |||
signatures that use unrecognized canonicalization algorithms. | signatures that use unrecognized canonicalization algorithms. | |||
[[NON-NORMATIVE DISCUSSION POINT: If a message is transmitted | ||||
using CHUNKING (that is, BDAT instead of the DATA command) and | ||||
BODY=BINARYMIME [RFC3030] then the body should be treated as a | ||||
binary stream, and no canonicalization whatsoever should be done. | ||||
Do we want to leave this for the future, say that canonicalization | ||||
is ignored in this circumstance, or add a third "binary" body | ||||
canonicalization algorithm? Or something else, of course.]] | ||||
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 16, line 7 | skipping to change at page 15, line 51 | |||
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. If there is no trailing | length after removal of the line terminator. If there is no trailing | |||
CRLF on the message, a CRLF is added. It makes no other changes to | CRLF on the message, a CRLF is added. It makes no other changes to | |||
the message body. In more formal terms, the "simple" body | the message body. In more formal terms, the "simple" body | |||
canonicalization algorithm converts "0*CRLF" at the end of the body | canonicalization algorithm converts "0*CRLF" at the end of the body | |||
to a single "CRLF". | 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" | 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 POINT (ISSUE 1326): Mike Thomas has | ||||
found bare CRs in the wild that are getting converted to CRLF by | ||||
some MTAs and thus breaking signatures. Shall we (a) drop | ||||
"relaxed" until we can figure out how to do it right and then put | ||||
it in as an extension, (b) change "relaxed" to handle this case, | ||||
probably by having it convert bare CR and LF to CRLF, or (c) | ||||
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. | message body is signed. | |||
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 | |||
skipping to change at page 17, line 28 | skipping to change at page 17, line 15 | |||
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. | |||
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" canonicalization algorithm for both | should specify the "simple" canonicalization algorithm for both | |||
header and body and omit the body length count. | 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, "<HTAB>" for a | bracketed descriptors: "<SP>" for a space character, "<HTAB>" for a | |||
tab character, and "<CRLF>" for a carriage-return/line-feed sequence. | tab character, and "<CRLF>" for a carriage-return/line-feed sequence. | |||
For example, "X <SP> Y" and "X<SP>Y" represent the same three | For example, "X <SP> Y" and "X<SP>Y" represent the same three | |||
characters.) | characters. | |||
Example 1: A message reading: | Example 1: A message reading: | |||
A: <SP> X <CRLF> | A: <SP> X <CRLF> | |||
B <SP> : <SP> Y <HTAB><CRLF> | B <SP> : <SP> Y <HTAB><CRLF> | |||
<HTAB> Z <SP><SP><CRLF> | <HTAB> Z <SP><SP><CRLF> | |||
<CRLF> | <CRLF> | |||
<SP> C <SP><CRLF> | <SP> C <SP><CRLF> | |||
D <SP><HTAB><SP> E <CRLF> | D <SP><HTAB><SP> E <CRLF> | |||
<CRLF> | <CRLF> | |||
<CRLF> | <CRLF> | |||
skipping to change at page 19, line 4 | skipping to change at page 18, line 37 | |||
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 an empty 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 encoded as described in section 6.7 of MIME Part | |||
[RFC2045], with the additional conversion of semicolon characters to | One [RFC2045], with the additional conversion of semicolon characters | |||
"=3B"; intuitively, this is one line of quoted-printable encoded | to "=3B"; intuitively, this is one line of quoted-printable encoded | |||
text. Tags described as dkim-quoted-printable are as defined in | text. The dkim-quoted-printable syntax is defined in Section 2.6. | |||
Section 2.6. | ||||
Tags on the DKIM-Signature header field along with their type and | Tags on the DKIM-Signature header field along with their type and | |||
requirement status are shown below. Unrecognized tags MUST be | requirement status are shown below. Unrecognized tags MUST be | |||
ignored. | ignored. | |||
v= Version (MUST be included). This tag defines the version of this | v= Version (MUST be included). This tag defines the version of this | |||
specification that applies to the signature record. It MUST have | specification that applies to the signature record. It MUST have | |||
the value 0.5. | the value 0.5. | |||
ABNF: | ABNF: | |||
skipping to change at page 24, line 19 | skipping to change at page 24, line 4 | |||
sig-q-tag-method = "dns/txt" / x-sig-q-tag-type ["/" x-sig-q-tag-args] | sig-q-tag-method = "dns/txt" / x-sig-q-tag-type ["/" x-sig-q-tag-args] | |||
x-sig-q-tag-type = hyphenated-word ; for future extension | x-sig-q-tag-type = hyphenated-word ; for future extension | |||
x-sig-q-tag-args = qp-hdr-value | x-sig-q-tag-args = qp-hdr-value | |||
s= The Selector subdividing the namespace for the "d=" (domain) tag | s= The Selector subdividing the namespace for the "d=" (domain) tag | |||
(plain-text; REQUIRED). | (plain-text; REQUIRED). | |||
ABNF: | ABNF: | |||
sig-s-tag = %x73 [FWS] "=" [FWS] selector | sig-s-tag = %x73 [FWS] "=" [FWS] selector | |||
t= Signature Timestamp (plain-text unsigned decimal integer; | t= Signature Timestamp (plain-text unsigned decimal integer; | |||
RECOMMENDED, default is an unknown creation time). The time that | RECOMMENDED, default is an unknown creation time). The time that | |||
this signature was created. The format is the number of seconds | this signature was created. The format is the number of seconds | |||
since 00:00:00 on January 1, 1970 in the UTC time zone. The | since 00:00:00 on January 1, 1970 in the UTC time zone. The | |||
value is expressed as an unsigned integer in decimal ASCII. This | value is expressed as an unsigned integer in decimal ASCII. This | |||
value is not constrained to fit into a 31- or 32-bit integer. | value is not constrained to fit into a 31- or 32-bit integer. | |||
Implementations SHOULD be prepared to handle values up to at | Implementations SHOULD be prepared to handle values up to at | |||
least 10^12 (until approximately AD 200,000; this fits into 40 | least 10^12 (until approximately AD 200,000; this fits into 40 | |||
bits). To avoid denial of service attacks, implementations MAY | bits). To avoid denial of service attacks, implementations MAY | |||
consider any value longer than 12 digits to be infinite. | consider any value longer than 12 digits to be infinite. Leap | |||
seconds are not counted. | ||||
ABNF: | ABNF: | |||
sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT | sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT | |||
x= Signature Expiration (plain-text unsigned decimal integer; | x= Signature Expiration (plain-text unsigned decimal integer; | |||
RECOMMENDED, default is no expiration). The format is the same | RECOMMENDED, default is no expiration). The format is the same | |||
as in the "t=" tag, represented as an absolute date, not as a | as in the "t=" tag, represented as an absolute date, not as a | |||
time delta from the signing timestamp. The value is expressed as | time delta from the signing timestamp. The value is expressed as | |||
an unsigned integer in decimal ASCII, with the same contraints on | an unsigned integer in decimal ASCII, with the same constraints | |||
the value in the "t=" tag. Signatures MAY be considered invalid | on the value in the "t=" tag. Signatures MAY be considered | |||
if the verification time at the verifier is past the expiration | invalid if the verification time at the verifier is past the | |||
date. The verification time should be the time that the message | expiration date. The verification time should be the time that | |||
was first received at the administrative domain of the verifier | the message was first received at the administrative domain of | |||
if that time is reliably available; otherwise the current time | the verifier if that time is reliably available; otherwise the | |||
should be used. The value of the "x=" tag MUST be greater than | current time should be used. The value of the "x=" tag MUST be | |||
the value of the "t=" tag if both are present. | greater than 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; | z= Copied header fields (dkim-quoted-printable, but see description; | |||
OPTIONAL, default is null). A vertical-bar-separated list of | OPTIONAL, default is null). A vertical-bar-separated list of | |||
selected header fields present when the message was signed, | selected header fields present when the message was signed, | |||
including both the field name and value. It is not required to | including both the field name and value. It is not required to | |||
include all header fields present at the time of signing. This | include all header fields present at the time of signing. This | |||
field need not contain the same header fields listed in the "h=" | field need not contain the same header fields listed in the "h=" | |||
tag. The header field text itself must encode the vertical bar | tag. The header field text itself must encode the vertical bar | |||
("|", %x7C) character (i.e., vertical bars in the z= text are | ("|", %x7C) character (i.e., vertical bars in the z= text are | |||
metacharacters, and any actual vertical bar characters in a | metacharacters, and any actual vertical bar characters in a | |||
copied header field must be encoded). Note that all white space | copied header field must be encoded). Note that all white space | |||
must be encoded, including white space between the colon and the | must be encoded, including white space between the colon and the | |||
header field value. After encoding, SWSP MAY be added at | header field value. After encoding, LWSP MAY be added at | |||
arbitrary locations in order to avoid excessively long lines; | arbitrary locations in order to avoid excessively long lines; | |||
such white space is NOT part of the value of the header field, | such white space is NOT part of the value of the header field, | |||
and MUST be removed before decoding. | 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 | |||
skipping to change at page 28, line 9 | skipping to change at page 27, line 40 | |||
[RFC3447] (see sections 3.1 and A.1.1) is being used in the p= | [RFC3447] (see sections 3.1 and A.1.1) is being used in the p= | |||
tag. (Note: the p= tag further encodes the value using the | tag. (Note: the p= tag further encodes the value using the | |||
base64 algorithm.) | 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 | ||||
hard to separate h= and k=; for example DSA implies that | ||||
SHA-1 will be used. This might be an actual change to the | ||||
spec depending on how we decide to fix this.]] | ||||
n= Notes that might be of interest to a human (qp-section; OPTIONAL, | n= Notes that might be of interest to a human (qp-section; OPTIONAL, | |||
default is empty). No interpretation is made by any program. | default is empty). No interpretation is made by any program. | |||
This tag should be used sparingly in any key server mechanism | This tag should be used sparingly in any key server mechanism | |||
that has space limitations (notably DNS). | that has space limitations (notably DNS). | |||
ABNF: | ABNF: | |||
key-n-tag = %x6e [FWS] "=" [FWS] qp-section | key-n-tag = %x6e [FWS] "=" [FWS] qp-section | |||
p= Public-key data (base64; REQUIRED). An empty value means that | p= Public-key data (base64; REQUIRED). An empty value means that | |||
this public key has been revoked. The syntax and semantics of | this public key has been revoked. The syntax and semantics of | |||
this tag value before being encoded in base64 is defined by the | this tag value before being encoded in base64 is defined by the | |||
k= tag. | k= tag. | |||
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- | |||
skipping to change at page 30, line 10 | skipping to change at page 29, line 34 | |||
"foo.bar._domainkey.example.com". | "foo.bar._domainkey.example.com". | |||
Wildcard DNS records (e.g., *.bar._domainkey.example.com) MUST NOT be | Wildcard DNS records (e.g., *.bar._domainkey.example.com) MUST NOT be | |||
used. Note also that wildcards within domains (e.g., | used. Note also that wildcards within domains (e.g., | |||
s._domainkey.*.example.com) are not supported by the DNS. | 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 Resource Record | |||
later extension of this standard may define another Resource Record | (RR). A later extension of this standard may define another RR type. | |||
type. | ||||
TXT records are encoded as described in Section 3.6.1. | Strings in a TXT RR MUST be concatenated together before use with no | |||
intervening white space. TXT RRs MUST be unique for a particular | ||||
selector name; that is, if there are multiple records in an RRset, | ||||
the results are undefined. | ||||
TXT RRs are encoded as described in Section 3.6.1. | ||||
3.7 Computing the Message Hashes | 3.7 Computing the Message Hashes | |||
Both signing and verifying message signatures 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 | |||
discussion, the names of the tags in the "DKIM-Signature" header | discussion, the names of the tags in the "DKIM-Signature" header | |||
field which either exists (when verifying) or will be created (when | field which either exists (when verifying) or will be created (when | |||
signing) are used. Note that canonicalization (Section 3.4) is only | signing) are used. Note that canonicalization (Section 3.4) is only | |||
used to prepare the email for signing or verifying; it does not | used to prepare the email for signing or verifying; it does not | |||
affect the transmitted email in any way. | affect the transmitted email in any way. | |||
The signer or verifier must compute two hashes, one over the body of | The signer or verifier MUST compute two hashes, one over the body of | |||
the message and one over the selected header fields of the message. | the message and one over the selected header fields of the message. | |||
Signers MUST compute them in the order shown. Verifiers MAY compute | Signers MUST compute them in the order shown. Verifiers MAY compute | |||
them in any order convenient to the verifier, provided that the | them in any order convenient to the verifier, provided that the | |||
result is semantically identical to the semantics that would be the | result is semantically identical to the semantics that would be the | |||
case had they been computed in this order. | case had they been computed in this order. | |||
In hash step 1, the signer or verifier MUST hash the message body, | In hash step 1, the signer or verifier MUST hash the message body, | |||
canonicalized using the body canonicalization algorithm specified in | canonicalized using the body canonicalization algorithm specified in | |||
the "c=" tag and truncated to the length specified in the "l=" tag. | the "c=" tag and truncated to the length specified in the "l=" tag. | |||
That hash value is then converted to base64 form and inserted into | That hash value is then converted to base64 form and inserted into | |||
the "bh=" tag of the DKIM-Signature: header field. | the "bh=" tag of the DKIM-Signature: header field. | |||
In hash step 2, the signer or verifier MUST pass the following to the | In hash step 2, the signer or verifier MUST pass the following to the | |||
hash algorithm in the indicated order. | hash algorithm in the indicated order. | |||
1. The header fields specified by the "h=" tag, in the order | 1. The header fields specified by the "h=" tag, in the order | |||
specified in that tag, and canonicalized using the header | specified in that tag, and canonicalized using the header | |||
canonicalization algorithm specified in the "c=" tag. Each | canonicalization algorithm specified in the "c=" tag. Each | |||
header field must be terminated with a single CRLF. | header field MUST be terminated with a single CRLF. | |||
2. The "DKIM-Signature" header field that exists (verifying) or will | 2. The "DKIM-Signature" header field that exists (verifying) or will | |||
be inserted (signing) in the message, with the value of the "b=" | be inserted (signing) in the message, with the value of the "b=" | |||
tag deleted (i.e., treated as the empty string), canonicalized | tag deleted (i.e., treated as the empty string), canonicalized | |||
using the header canonicalization algorithm specified in the "c=" | using the header canonicalization algorithm specified in the "c=" | |||
tag, and without a trailing CRLF. | tag, and without a trailing CRLF. | |||
All tags and their values in the DKIM-Signature header field are | All tags and their values in the DKIM-Signature header field are | |||
included in the cryptographic hash with the sole exception of the | included in the cryptographic hash with the sole exception of the | |||
value portion of the "b=" (signature) tag, which MUST be treated as | value portion of the "b=" (signature) tag, which MUST be treated as | |||
skipping to change at page 31, line 45 | skipping to change at page 31, line 26 | |||
signature = sig-alg(header-hash, key) | signature = sig-alg(header-hash, key) | |||
where "sig-alg" is the signature algorithm specified by the "a=" tag, | where "sig-alg" is the signature algorithm specified by the "a=" tag, | |||
"hash-alg" is the hash algorithm specified by the "a=" tag, | "hash-alg" is the hash algorithm specified by the "a=" tag, | |||
"canon_header" and "canon_body" are the canonicalized message header | "canon_header" and "canon_body" are the canonicalized message header | |||
and body (respectively) as defined in Section 3.4 (excluding the | and body (respectively) as defined in Section 3.4 (excluding the | |||
DKIM-Signature header field), and "DKIM-SIG" is the canonicalized | DKIM-Signature header field), and "DKIM-SIG" is the canonicalized | |||
DKIM-Signature header field sans the signature value itself, but with | DKIM-Signature header field sans the signature value itself, but with | |||
"body-hash" included as the "bh=" tag. | "body-hash" included as the "bh=" tag. | |||
INFORMATIVE NOTE: Many digital signature APIs provide both | INFORMATIVE IMPLEMENTERS' NOTE: Many digital signature APIs | |||
hashing and application of the RSA private key using a single | provide both hashing and application of the RSA private key using | |||
"sign()" primitive. When using such an API the last two steps in | a single "sign()" primitive. When using such an API the last two | |||
the algorithm would probably be combined into a single call that | steps in the algorithm would probably be combined into a single | |||
would perform both the "hash-alg" and the "sig-alg". | call that would perform both the "hash-alg" and the "sig-alg". | |||
3.8 Signing by Parent Domains | 3.8 Signing by Parent Domains | |||
In some circumstances, it is desirable for a domain to apply a | In some circumstances, it is desirable for a domain to apply a | |||
signature on behalf of any of its subdomains without the need to | signature on behalf of any of its subdomains without the need to | |||
maintain separate selectors (key records) in each subdomain. By | maintain separate selectors (key records) in each subdomain. By | |||
default, private keys corresponding to key records can be used to | default, private keys corresponding to key records can be used to | |||
sign messages for any subdomain of the domain in which they reside, | sign messages for any subdomain of the domain in which they reside, | |||
e.g., a key record for the domain example.com can be used to verify | 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 | messages where the signing identity (i= tag of the signature) is | |||
skipping to change at page 32, line 29 | skipping to change at page 32, line 9 | |||
the domain of the signing identity (i= flag) MUST be the same as that | 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 | 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 | identity MUST be the same as, or a subdomain of, the d= domain. Key | |||
records which are not intended for use with subdomains SHOULD specify | records which are not intended for use with subdomains SHOULD specify | |||
the "s" flag in the t= tag. | the "s" flag in the t= tag. | |||
4. Semantics of Multiple Signatures | 4. Semantics of Multiple Signatures | |||
A signer that is adding a signature to a message merely creates a new | A signer that is adding a signature to a message merely creates a new | |||
DKIM-Signature header, using the usual semantics of the h= option. A | DKIM-Signature header, using the usual semantics of the h= option. A | |||
signer MAY sign previously existing DKIM-Signature headers using the | signer MAY sign previously existing DKIM-Signature header fields | |||
method described in section Section 5.4 to sign trace headers. | using the method described in section Section 5.4 to sign trace | |||
Signers should be cognizant that signing DKIM-Signature headers may | headers. Signers should be cognizant that signing DKIM-Signature | |||
result in signature failures with intermediaries that do not | header fields may result in signature failures with intermediaries | |||
recognize that DKIM-Signatures are trace headers and unwittingly | that do not recognize that DKIM-Signature header fields are trace | |||
reorder them. | header fields and unwittingly 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 | |||
verifier. | verifier. | |||
skipping to change at page 33, line 46 | skipping to change at page 33, line 28 | |||
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 revoked or removed before the verifier has | key is expected to be revoked or removed before the verifier has | |||
an 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 | |||
to modification during transit, notably conversion to 7-bit form. | to modification during transit, notably conversion to 7-bit form. | |||
Such conversions will break DKIM signatures. In order to minimize | Such conversions will break DKIM signatures. In order to minimize | |||
the chances of such breakage, signers SHOULD convert the message to a | the chances of such breakage, signers SHOULD convert the message to a | |||
skipping to change at page 40, line 51 | skipping to change at page 40, line 25 | |||
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. | algorithm in the "q=" tag, the 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 occurring during the incoming | unavailable). If verification is occurring during the incoming | |||
SMTP session, this MAY be achieved with a 451/4.7.5 SMTP reply | SMTP session, this MAY be achieved with a 451/4.7.5 SMTP reply | |||
code. Alternatively, the verifier MAY store the message in the | code. Alternatively, the verifier MAY store the message in the | |||
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. | |||
skipping to change at page 45, line 23 | skipping to change at page 45, line 8 | |||
7.1 DKIM-Signature Tag Specifications | 7.1 DKIM-Signature Tag Specifications | |||
A DKIM-Signature provides for a list of tag specifications. IANA is | A DKIM-Signature provides for a list of tag specifications. IANA is | |||
requested to establish the DKIM Signature Tag Specification Registry, | requested to establish the DKIM Signature Tag Specification Registry, | |||
for tag specifications that can be used in DKIM-Signature fields and | for tag specifications that can be used in DKIM-Signature fields and | |||
that have been specified in any published RFC. | that have been specified in any published RFC. | |||
The initial entries in the registry comprise: | The initial entries in the registry comprise: | |||
+------+-----------------+ | +------+-----------------+ | |||
| TYPE | RFC | | | TYPE | REFERENCE | | |||
+------+-----------------+ | +------+-----------------+ | |||
| v | (this document) | | | v | (this document) | | |||
| a | (this document) | | | a | (this document) | | |||
| b | (this document) | | | b | (this document) | | |||
| bh | (this document) | | | bh | (this document) | | |||
| c | (this document) | | | c | (this document) | | |||
| d | (this document) | | | d | (this document) | | |||
| h | (this document) | | | h | (this document) | | |||
| i | (this document) | | | i | (this document) | | |||
| l | (this document) | | | l | (this document) | | |||
skipping to change at page 46, line 8 | skipping to change at page 45, line 39 | |||
query methods. | query methods. | |||
IANA is requested to establish the DKIM Query Method Registry, for | IANA is requested to establish the DKIM Query Method Registry, for | |||
mechanisms that can be used to retrieve the key that will permit | mechanisms that can be used to retrieve the key that will permit | |||
validation processing of a message signed using DKIM and have been | validation processing of a message signed using DKIM and have been | |||
specified in any published RFC. | specified in any published RFC. | |||
The initial entry in the registry comprises: | The initial entry in the registry comprises: | |||
+------+--------+-----------------+ | +------+--------+-----------------+ | |||
| TYPE | OPTION | RFC | | | TYPE | OPTION | REFERENCE | | |||
+------+--------+-----------------+ | +------+--------+-----------------+ | |||
| dns | txt | (this document) | | | dns | txt | (this document) | | |||
+------+--------+-----------------+ | +------+--------+-----------------+ | |||
7.3 DKIM-Signature Canonicalization Registry | 7.3 DKIM-Signature Canonicalization Registry | |||
The "c=" tag-spec, as specified in Section 3.5 provides for a | The "c=" tag-spec, as specified in Section 3.5 provides for a | |||
specifier for canonicalization algorithms for the header and body of | specifier for canonicalization algorithms for the header and body of | |||
the message. | the message. | |||
IANA is requested to establish the DKIM Canonicalization Algorithm | IANA is requested to establish the DKIM Canonicalization Algorithm | |||
Registry, for algorithms for converting a message into a canonical | Registry, for algorithms for converting a message into a canonical | |||
form before signing or verifying using DKIM and have been specified | form before signing or verifying using DKIM and have been specified | |||
in any published RFC. | in any published RFC. | |||
The initial entries in the header registry comprise: | The initial entries in the header registry comprise: | |||
+---------+-----------------+ | +---------+-----------------+ | |||
| TYPE | RFC | | | TYPE | REFERENCE | | |||
+---------+-----------------+ | +---------+-----------------+ | |||
| simple | (this document) | | | simple | (this document) | | |||
| relaxed | (this document) | | | relaxed | (this document) | | |||
+---------+-----------------+ | +---------+-----------------+ | |||
The initial entries in the body registry comprise: | The initial entries in the body registry comprise: | |||
+---------+-----------------+ | +---------+-----------------+ | |||
| TYPE | RFC | | | TYPE | REFERENCE | | |||
+---------+-----------------+ | +---------+-----------------+ | |||
| simple | (this document) | | | simple | (this document) | | |||
| relaxed | (this document) | | | relaxed | (this document) | | |||
+---------+-----------------+ | +---------+-----------------+ | |||
7.4 _domainkey DNS TXT Record Tag Specifications | 7.4 _domainkey DNS TXT Record Tag Specifications | |||
A _domainkey DNS TXT record provides for a list of tag | A _domainkey DNS TXT record provides for a list of tag | |||
specifications. IANA is requested to establish the DKIM _domainkey | specifications. IANA is requested to establish the DKIM _domainkey | |||
DNS TXT Tag Specification Registry, for tag specifications that can | DNS TXT Tag Specification Registry, for tag specifications that can | |||
be used in DNS TXT Records and that have been specified in any | be used in DNS TXT Records and that have been specified in any | |||
published RFC. | published RFC. | |||
The initial entries in the registry comprise: | The initial entries in the registry comprise: | |||
+------+-----------------+ | +------+-----------------+ | |||
| TYPE | RFC | | | TYPE | REFERENCE | | |||
+------+-----------------+ | +------+-----------------+ | |||
| v | (this document) | | | v | (this document) | | |||
| g | (this document) | | | g | (this document) | | |||
| h | (this document) | | | h | (this document) | | |||
| k | (this document) | | | k | (this document) | | |||
| n | (this document) | | | n | (this document) | | |||
| p | (this document) | | | p | (this document) | | |||
| s | (this document) | | | s | (this document) | | |||
| t | (this document) | | | t | (this document) | | |||
+------+-----------------+ | +------+-----------------+ | |||
skipping to change at page 47, line 31 | skipping to change at page 47, line 16 | |||
The "k=" <key-k-tag> (as specified in Section 3.6.1) and the "a=" | 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 | <sig-a-tag-k> (Section 3.5) tags provide for a list of mechanisms | |||
that can be used to decode a DKIM signature. | that can be used to decode a DKIM signature. | |||
IANA is requested to establish the DKIM Key Type Registry, for such | IANA is requested to establish the DKIM Key Type Registry, for such | |||
mechanisms that have been specified in any published RFC. | mechanisms that have been specified in any published RFC. | |||
The initial entry in the registry comprises: | The initial entry in the registry comprises: | |||
+------+---------+ | +------+-----------+ | |||
| TYPE | RFC | | | TYPE | REFERENCE | | |||
+------+---------+ | +------+-----------+ | |||
| rsa | RFC3447 | | | rsa | [RFC3447] | | |||
+------+---------+ | +------+-----------+ | |||
7.6 DKIM Hash Algorithms Registry | 7.6 DKIM Hash Algorithms Registry | |||
The "h=" <key-h-tag> list (specified in Section 3.6.1) and the "a=" | 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 | <sig-a-tag-h> (Section 3.5) provide for a list of mechanisms that can | |||
be used to produce a digest of message data. | be used to produce a digest of message data. | |||
IANA is requested to establish the DKIM Hash Algorithms Registry, for | IANA is requested to establish the DKIM Hash Algorithms Registry, for | |||
such mechanisms that have been specified in any published RFC. | such mechanisms that have been specified in any published RFC. | |||
The initial entries in the registry comprise: | The initial entries in the registry comprise: | |||
+--------+-----+ | +--------+-----------+ | |||
| TYPE | RFC | | | TYPE | REFERENCE | | |||
+--------+-----+ | +--------+-----------+ | |||
| sha1 | ? | | | sha1 | [SHA] | | |||
| sha256 | ? | | | sha256 | [SHA] | | |||
+--------+-----+ | +--------+-----------+ | |||
7.7 DKIM Service Types Registry | 7.7 DKIM Service Types Registry | |||
The "s=" <key-s-tag> list (specified in Section 3.6.1) provides for a | The "s=" <key-s-tag> list (specified in Section 3.6.1) provides for a | |||
list of service types to which this selector may apply. | list of service types to which this selector may apply. | |||
IANA is requested to establish the DKIM Service Types Registry, for | IANA is requested to establish the DKIM Service Types Registry, for | |||
service types that have been specified in any published RFC. | service types that have been specified in any published RFC. | |||
The initial entries in the registry comprise: | The initial entries in the registry comprise: | |||
+-------+-----------------+ | +-------+-----------------+ | |||
| TYPE | RFC | | | TYPE | REFERENCE | | |||
+-------+-----------------+ | +-------+-----------------+ | |||
| email | (this document) | | | email | (this document) | | |||
| * | (this document) | | | * | (this document) | | |||
+-------+-----------------+ | +-------+-----------------+ | |||
7.8 DKIM Selector Flags Registry | 7.8 DKIM Selector Flags Registry | |||
The "t=" <key-t-tag> list (specified in Section 3.6.1) provides for a | The "t=" <key-t-tag> list (specified in Section 3.6.1) provides for a | |||
list of flags to modify interpretation of the selector. | list of flags to modify interpretation of the selector. | |||
IANA is requested to establish the DKIM Selector Flags Registry, for | IANA is requested to establish the DKIM Selector Flags Registry, for | |||
additional flags that have been specified in any published RFC. | additional flags that have been specified in any published RFC. | |||
The initial entries in the registry comprise: | The initial entries in the registry comprise: | |||
+------+-----------------+ | +------+-----------------+ | |||
| TYPE | RFC | | | TYPE | REFERENCE | | |||
+------+-----------------+ | +------+-----------------+ | |||
| y | (this document) | | | y | (this document) | | |||
| s | (this document) | | | s | (this document) | | |||
+------+-----------------+ | +------+-----------------+ | |||
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 | |||
skipping to change at page 53, line 43 | skipping to change at page 53, line 23 | |||
Standards (PKCS) #1: RSA Cryptography Specifications | Standards (PKCS) #1: RSA Cryptography Specifications | |||
Version 2.1", RFC 3447, February 2003. | Version 2.1", RFC 3447, February 2003. | |||
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, | [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, | |||
"Internationalizing Domain Names in Applications (IDNA)", | "Internationalizing Domain Names in Applications (IDNA)", | |||
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. | |||
[SHA] U.S. Department of Commerce, "Secure Hash Standard", FIPS | ||||
PUB 180-2, August 2002. | ||||
[X.660] "ITU-T Recommendation X.660 Information Technology - ASN.1 | [X.660] "ITU-T Recommendation X.660 Information Technology - ASN.1 | |||
encoding rules: Specification of Basic Encoding Rules | encoding rules: Specification of Basic Encoding Rules | |||
(BER), Canonical Encoding Rules (CER) and Distinguished | (BER), Canonical Encoding Rules (CER) and Distinguished | |||
Encoding Rules (DER)", 1997. | Encoding Rules (DER)", 1997. | |||
9.2 Informative References | 9.2 Informative References | |||
[BONEH03] Proc. 12th USENIX Security Symposium, "Remote Timing | [BONEH03] Proc. 12th USENIX Security Symposium, "Remote Timing | |||
Attacks are Practical", 2003, <http://www.usenix.org/ | Attacks are Practical", 2003, <http://www.usenix.org/ | |||
publications/library/proceedings/sec03/tech/brumley.html>. | publications/library/proceedings/sec03/tech/brumley.html>. | |||
skipping to change at page 58, line 33 | skipping to change at page 57, line 47 | |||
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. | |||
Appendix B. Usage Examples (INFORMATIVE) | Appendix B. Usage Examples (INFORMATIVE) | |||
Studies in this appendix are for informational purposes only. In no | DKIM signing and validating can be used in different ways, for | |||
case should these examples be used as guidance when creating an | different operational scenarios. This Appendix discusses some common | |||
examples. | ||||
NOTE: Descriptions in this Appendix are for informational | ||||
purposes only. They describe various ways that DKIM can be used, | ||||
given particular constraints and needs. In no case are these | ||||
examples intended to be taken as providing explanation or guidance | ||||
concerning DKIM specification details, when creating an | ||||
implementation. | implementation. | |||
B.1 Simple Message Forwarding | B.1 Alternate Submission Scenarios | |||
In some cases the recipient may request forwarding of email messages | In the most simple scenario, a user's MUA, MSA, and Internet | |||
from the original address to another, through the use of a Unix | (boundary) MTA are all within the same administrative environment, | |||
.forward file or equivalent. In this case messages are typically | using the same domain name. Therefore, all of the components | |||
forwarded without modification, except for the addition of a Received | involved in submission and initial transfer are related. However it | |||
header field to the message and a change in the Envelope-to address. | is common for two or more of the components to be under independent | |||
In this case, the eventual recipient should be able to verify the | administrative control. This creates challenges for choosing and | |||
original signature since the signed content has not changed, and | administering the domain name to use for signing, and for its | |||
attribute the message correctly. | relationship to common email identity header fields. | |||
B.2 Outsourced Business Functions | B.1.1 Delegated Business Functions | |||
Outsourced business functions represent a use case that motivates the | Some organizations assign specific business functions to discrete | |||
need for Selectors (the "s=" signature tag) and granularity (the "g=" | groups, inside or outside the organization. The goal, then, is to | |||
key tag). Examples of outsourced business functions are legitimate | authorize that group to sign some mail, but to constrain what | |||
email marketing providers and corporate benefits providers. In | signatures they can generate. DKIM Selectors (the "s=" signature | |||
either case, the outsourced function would like to be able to send | tag) and granularity (the "g=" key tag) facilitate this kind of | |||
messages using the email domain of the client company. At the same | restricted authorization. Examples of these outsourced business | |||
time, the client may be reluctant to register a key for the provider | functions are legitimate email marketing providers and corporate | |||
that grants the ability to send messages for any address in the | benefits providers. | |||
domain. | ||||
The outsourcing company can generate a keypair and the client company | Here, the delegated group needs to be able to send messages that are | |||
can register the public key using a unique Selector for a specific | signed, using the email domain of the client company. At the same | |||
address such as winter-promotions@example.com by specifying a | time, the client often is reluctant to register a key for the | |||
granularity of "g=winter-promotions" or "g=*-promotions" (to allow a | provider that grants the ability to send messages for arbitrary | |||
range of addresses). This would enable the provider to send messages | addresses in the domain. | |||
using that specific address and have them verify properly. The | ||||
client company retains control over the email address because it | ||||
retains the ability to revoke the key at any time. | ||||
B.3 PDAs and Similar Devices | There are multiple ways to administer these usage scenarios. In one | |||
case, the client organization provides all of the public query | ||||
service (for example, DNS) administration, and in another it uses DNS | ||||
delegation to enable all on-going administration of the DKIM key | ||||
record by the delegated group. | ||||
PDAs are one example of the use of multiple keys per user. Suppose | If the client organization retains responsibility for all of the DNS | |||
that John Doe wanted to be able to send messages using his corporate | administration, the outsourcing company can generate a key pair, | |||
email address, jdoe@example.com, and the device did not have the | supplying the public key to the client company, which then registers | |||
ability to make a VPN connection to the corporate network. If the | it in the query service, using a unique Selector that authorizes a | |||
device was equipped with a private key registered for | specific From header field local-part. For example, a client with | |||
jdoe@example.com by the administrator of that domain, and appropriate | the domain "example.com" could have the Selector record specify | |||
software to sign messages, John could send signed messages through | "g=winter-promotions" so that this signature is only valid for mail | |||
the outgoing network of the PDA service provider. | with a From address of "winter-promotions@example.com". This would | |||
enable the provider to send messages using that specific address and | ||||
have them verify properly. The client company retains control over | ||||
the email address because it retains the ability to revoke the key at | ||||
any time. | ||||
B.4 Mailing Lists | If the client wants the delegated group to do the DNS administration, | |||
it can have the domain name that is specified with the selector point | ||||
to the provider's DNS server. The provider then creates and | ||||
maintains all of the DKIM signature information for that Selector. | ||||
Hence, the client cannot provide constraints on the local-part of | ||||
addresses that get signed, but it can revoke the provider's signing | ||||
rights by removing the DNS delegation record. | ||||
There is a wide range of behavior in forwarders and mailing lists | B.1.2 PDAs and Similar Devices | |||
(collectively called "forwarders" below), ranging from those which | ||||
make no modification to the message itself (other than to add a | ||||
Received header field and change the envelope information) to those | ||||
which may add header fields, change the Subject header field, add | ||||
content to the body (typically at the end), or reformat the body in | ||||
some manner. | ||||
Forwarders which do not modify the body or signed header fields of a | PDAs demonstrate the need for using multiple keys per domain. | |||
message with a valid signature may re-sign the message as described | Suppose that John Doe wanted to be able to send messages using his | |||
below. | corporate email address, jdoe@example.com, and his email device did | |||
not have the ability to make a VPN connection to the corporate | ||||
network, either because the device is limited or because there are | ||||
restrictions enforced by his Internet access provider. If the device | ||||
was equipped with a private key registered for jdoe@example.com by | ||||
the administrator of the example.com domain, and appropriate software | ||||
to sign messages, John could sign the message on the device itself | ||||
before transmission through the outgoing network of the access | ||||
service provider. | ||||
Forwarders which make any modification to a message that could result | B.1.3 Roaming Users | |||
in its signature becoming invalid should sign or re-sign using an | ||||
appropriate identification (e.g., mailing-list-name@example.net). | ||||
Since in so doing the (re-)signer is taking responsibility for the | ||||
content of the message, modifying forwarders may elect to forward or | ||||
re-sign only for messages which were received with valid signatures | ||||
or other indications that the messages being signed are not spoofed. | ||||
Forwarders which wish to re-sign a message must apply a Sender header | Roaming users often find themselves in circumstances where it is | |||
field to the message to identify the address being used to sign the | convenient or necessary to use an SMTP server other than their home | |||
message and must remove any preexisting Sender header field as | server; examples are conferences and many hotels. In such | |||
required by [RFC2822]. The forwarder applies a new DKIM-Signature | circumstances a signature that is added by the submission service | |||
header field with the signature, public key, and related information | will use an identity that is different from the user's home system. | |||
of the forwarder. | ||||
B.5 Affinity Addresses | 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 is high. If neither of these are possible, | ||||
these roaming users will not be able to send mail signed using their | ||||
own domain key. | ||||
"Affinity addresses" are email addresses that users employ to have an | B.1.4 Independent (Kiosk) Message Submission | |||
email address that is independent of any changes in email service | ||||
provider they may choose to make. They are typically associated with | Stand-alone services, such as walk-up kiosks and web-based | |||
college alumni associations, professional organizations, and | information services, have no enduring email service relationship | |||
recreational organizations with which they expect to have a long-term | with the user, but the user occasionally requests that mail be sent | |||
on their behalf. For example, a website providing news often allows | ||||
the reader to forward a copy of the article to a friend. This is | ||||
typically done using the reader's own email address, to indicate who | ||||
the author is. This is sometimes referred to as the "Evite problem", | ||||
named after the website of the same name that allows a user to send | ||||
invitations to friends. | ||||
A common way this is handled is to continue to put the reader's email | ||||
address in the From header field of the message, but put an address | ||||
owned by the email posting site into the Sender header field. The | ||||
posting site can then sign the message, using the domain that is in | ||||
the Sender field. This provides useful information to the receiving | ||||
email site, which is able to correlate the signing domain with the | ||||
initial submission email role. | ||||
Receiving sites often wish to provide their end users with | ||||
information about mail that is mediated in this fashion. Although | ||||
the real efficacy of different approaches is a subject for human | ||||
factors usability research, one technique that is used is for the | ||||
verifying system to rewrite the From header field, to indicate the | ||||
address that was verified. For example: From: John Doe via | ||||
news@news-site.com <jdoe@example.com>. (Note that, such rewriting | ||||
will break a signature, unless it is done after the verification pass | ||||
is complete.) | ||||
B.2 Alternate Delivery Scenarios | ||||
Email is often received at a mailbox that has an address different | ||||
from the one used during initial submission. In these cases, an | ||||
intermediary mechanism operates at the address originally used and it | ||||
then passes the message on to the final destination. This mediation | ||||
process presents some challenges for DKIM signatures. | ||||
B.2.1 Affinity Addresses | ||||
"Affinity addresses" allow a user to have an email address that | ||||
remains stable, even as the user moves among different email | ||||
providers. They are typically associated with college alumni | ||||
associations, professional organizations, and recreational | ||||
organizations with which they expect to have a long-term | ||||
relationship. These domains usually provide forwarding of incoming | relationship. These domains usually provide forwarding of incoming | |||
email, but (currently) usually depend on the user to send outgoing | email, and they often have an associated Web application which | |||
messages through their own service provider's MTA. They usually have | authenticates the user and allows the forwarding address to be | |||
an associated Web application which authenticates the user and allows | changed. However these services usually depend on the user's sending | |||
the forwarding address to be changed. | outgoing messages through their own service provider's MTA. Hence, | |||
mail that is signed with the domain of the affinity address is not | ||||
signed by an entity that is administered by the organization owning | ||||
that domain. | ||||
With DKIM, affinity domains could use the Web application to allow | With DKIM, affinity domains could use the Web application to allow | |||
users to register their own public keys to be used to sign messages | users to register per-user keys to be used to sign messages on behalf | |||
on behalf of their affinity address. This is another application | of their affinity address. The user would take away the secret half | |||
that takes advantage of user-level keying, and domains used for | of the key pair for signing, and the affinity domain would publish | |||
affinity addresses would typically have a very large number of user- | the public half in DNS for access by verifiers. | |||
level keys. Alternatively, the affinity domain could handle outgoing | ||||
mail, operating a mail submission agent that authenticates users | ||||
before accepting and signing messages for them. This is of course | ||||
dependent on the user's service provider not blocking the relevant | ||||
TCP ports used for mail submission. | ||||
B.6 Third-party Message Transmission | This is another application that takes advantage of user-level | |||
keying, and domains used for affinity addresses would typically have | ||||
a very large number of user-level keys. Alternatively, the affinity | ||||
domain could handle outgoing mail, operating a mail submission agent | ||||
that authenticates users before accepting and signing messages for | ||||
them. This is of course dependent on the user's service provider not | ||||
blocking the relevant TCP ports used for mail submission. | ||||
Third-party message transmission refers to the authorized sending of | B.2.2 Simple Address Aliasing (.forward) | |||
mail by an Internet application on behalf of a user. For example, a | ||||
website providing news may allow the reader to forward a copy of the | ||||
message to a friend; this is typically done using the reader's email | ||||
address. This is sometimes referred to as the "Evite problem", named | ||||
after the website of the same name that allows a user to send | ||||
invitations to friends. | ||||
One way this can be handled is to continue to put the reader's email | In some cases a recipient is allowed to configure an email address to | |||
address in the From header field of the message, but put an address | cause automatic redirection of email messages from the original | |||
owned by the site into the Sender header field, and sign the message | address to another, such as through the use of a Unix .forward file. | |||
on behalf of that address. A verifying MTA could accept this and | In this case messages are typically redirected by the mail handling | |||
rewrite the From header field to indicate the address that was | service of the recipient's domain, without modification, except for | |||
verified, i.e., From: John Doe via news@news-site.com | the addition of a Received header field to the message and a change | |||
<jdoe@example.com>. (However, such rewriting must be done after the | in the envelope recipient address. In this case, the recipient at | |||
verification pass is complete, and will break any later attempts to | the final address' mailbox is likely to be able to verify the | |||
re-verify.) | original signature since the signed content has not changed, and DKIM | |||
is able to validate the message signature. | ||||
B.7 SMTP Servers for Roaming Users | B.2.3 Mailing Lists and Re-Posters | |||
Roaming users may find themselves in circumstances where it is | There is a wide range of behaviors in services that take delivery of | |||
convenient or necessary to use an SMTP server other than their home | a message and then resubmit it. A primary example is with mailing | |||
server; examples are IETF conferences and many hotels. In such | lists (collectively called "forwarders" below), ranging from those | |||
circumstances the signature, if any, will be added by a party other | which make no modification to the message itself, other than to add a | |||
than the user's home system. | Received header field and change the envelope information, to those | |||
which add header fields, change the Subject header field, add content | ||||
to the body (typically at the end), or reformat the body in some | ||||
manner. The simple ones produces messages that are quite similar to | ||||
the automated alias services. More elaborate systems essentially | ||||
create a new message. | ||||
Ideally roaming users would connect back to their home server using | A Forwarder which does not modify the body or signed header fields of | |||
either a VPN or a SUBMISSION server running with SMTP AUTHentication | a message is likely to maintain the validity of the existing | |||
on port 587. If the signing can be performed on the roaming user's | signature. It also could choose to add its own signature to the | |||
laptop then they can sign before submission, although the risk of | message. | |||
further modification may be high. If neither of these are possible, | ||||
these roaming users will not be able to send mail signed using their | Forwarders which modify a message in a way that could make an | |||
own domain key. | existing signature invalid are particularly good candidates for | |||
adding their own signatures (e.g., mailing-list-name@example.net). | ||||
Since (re-)signing is taking responsibility for the content of the | ||||
message, these signing forwarders are likely to be selective, and | ||||
forward or re-sign only those messages which are received with a | ||||
valid signature or some other basis for knowing that the messages | ||||
being signed is not spoofed. | ||||
A common practice among systems that are primarily re-distributors of | ||||
mail is to add a Sender header field to the message, to identify the | ||||
address being used to sign the message. This practice will remove | ||||
any preexisting Sender header field as required by [RFC2822]. The | ||||
forwarder applies a new DKIM-Signature header field with the | ||||
signature, public key, and related information of the forwarder. | ||||
Appendix C. Creating a public key (INFORMATIVE) | Appendix C. Creating a public key (INFORMATIVE) | |||
The default signature is an RSA signed SHA256 digest of the complete | The default signature is an RSA signed SHA256 digest of the complete | |||
email. For ease of explanation, the openssl command is used to | email. For ease of explanation, the openssl command is used to | |||
describe the mechanism by which keys and signatures are managed. One | describe the mechanism by which keys and signatures are managed. One | |||
way to generate a 1024 bit, unencrypted private-key suitable for | way to generate a 1024 bit, unencrypted private-key suitable for | |||
DKIM, is to use openssl like this: | DKIM, is to use openssl like this: | |||
$ openssl genrsa -out rsa.private 1024 | $ openssl genrsa -out rsa.private 1024 | |||
skipping to change at page 63, line 15 | skipping to change at page 64, line 15 | |||
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: | The final record entered into a DNS zone file would be: | |||
brisbane IN TXT ("v=DKIM1; p=aoiDeX42BB/gP4ScqTdIQJcpAObYr+54yvct" | brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ" | |||
"qc4rSEFYby9+omKD3pJ/TVxATeTzmsybuW3WZiamb+mvn7f" | "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt" | |||
"3rhmnozHJ0yORQbnn4qJQhPbbPbWEQKW09AMJbyz/0lsl" ) | "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v" | |||
"/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi" | ||||
"tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB") | ||||
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, the processing system sometimes | |||
signing identity. MUAs might highlight the address associated with | makes the result available to the recipient user's MUA. How to | |||
this identity in some way to show the user the address from which the | present this information to the user in a way that helps them is a | |||
mail is sent. An MUA might do this with visual cues such as | matter of continuing human factors usability research. The tendency | |||
graphics, or it might include the address in an alternate views, or | is to have the MUA highlight the address associated with this signing | |||
identity in some way, in an attempt to show the user the address from | ||||
which the mail was sent. An MUA might do this with visual cues such | ||||
as graphics, or it might include the address in an alternate view, or | ||||
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 indicate which header fields were | |||
covered in a validated DKIM signature. This might be done with a | protected by the validated DKIM signature. This could be done with a | |||
positive indication on the signed headers, it might be done with a | positive indication on the signed header fields, or with a negative | |||
negative indication on the unsigned headers or visually hiding the | indication on the unsigned headers or by visually hiding the unsigned | |||
unsigned headers, or some combination of both. If an MUA uses visual | headers, or some combination of these. If an MUA uses visual | |||
indications for signed headers, the MUA needs to be careful not to | indications for signed headers, the MUA probably needs to be careful | |||
display unsigned headers in a way that might be construed by the end | not to display unsigned headers in a way that might be construed by | |||
user as having been signed. If the message has an l= tag whose value | the end user as having been signed. If the message has an l= tag | |||
does not extend to the end of the message, he MUA might also hide or | whose value does not extend to the end of the message, the MUA might | |||
mark the portion of the message body that is not signed. | also hide or mark the portion of the message body that was not | |||
signed. | ||||
The aforementioned information is not intended to be exhaustive. The | The aforementioned information is not intended to be exhaustive. The | |||
MUA may choose to highlight, accentuate, hide, or otherwise display | MUA may choose to highlight, accentuate, hide, or otherwise display | |||
any other information that may, in the opinion of the MUA author, be | any other information that may, in the opinion of the MUA author, be | |||
deemed important to the end user. | deemed important to the end user. | |||
Appendix E. Acknowledgements | Appendix E. Acknowledgements | |||
The authors wish to thank Russ Allbery, Edwin Aoki, Claus Assmann, | The authors wish to thank Russ Allbery, Edwin Aoki, Claus Assmann, | |||
Steve Atkins, Fred Baker, Mark Baugher, Nathaniel Borenstein, Dave | Steve Atkins, Fred Baker, Mark Baugher, Steve Bellovin, Nathaniel | |||
Crocker, Michael Cudahy, Dennis Dayman, Jutta Degener, Patrik | Borenstein, Dave Crocker, Michael Cudahy, Dennis Dayman, Jutta | |||
Faltstrom, Duncan Findlay, Elliot Gillum, Phillip Hallam-Baker, Tony | Degener, Patrik Faltstrom, Mark Fanto, Stephen Farrell, Duncan | |||
Hansen, Arvel Hathcock, Amir Herzberg, Paul Hoffman, Craig Hughes, | Findlay, Elliot Gillum, Phillip Hallam-Baker, Tony Hansen, Sam | |||
Don Johnsen, Harry Katz, Murray S. Kucherawy, Barry Leiba, John | Hartman, Arvel Hathcock, Amir Herzberg, Paul Hoffman, Russ Housley, | |||
Levine, Simon Longsdale, David Margrave, Justin Mason, David Mayne, | Craig Hughes, Don Johnsen, Harry Katz, Murray S. Kucherawy, Barry | |||
Steve Murphy, Russell Nelson, Dave Oran, Doug Otis, Shamim Pirzada, | Leiba, John Levine, Simon Longsdale, David Margrave, Justin Mason, | |||
Juan Altmayer Pizzorno, Sanjay Pol, Blake Ramsdell, Christian Renaud, | David Mayne, Steve Murphy, Russell Nelson, Dave Oran, Doug Otis, | |||
Scott Renfro, Eric Rescorla, Dave Rossetti, Hector Santos, the | Shamim Pirzada, Juan Altmayer Pizzorno, Sanjay Pol, Blake Ramsdell, | |||
Spamhaus.org team, Malte S. Stretz, Robert Sanders, Rand Wacker, and | Christian Renaud, Scott Renfro, Neil Rerup, Eric Rescorla, Dave | |||
Dan Wing for their valuable suggestions and constructive criticism. | Rossetti, Hector Santos, Jim Schaad, the Spamhaus.org team, Malte S. | |||
Stretz, Robert Sanders, Rand Wacker, Sam Weiler, and Dan Wing for | ||||
their valuable suggestions and constructive criticism. | ||||
The DomainKeys specification was a primary source from which this | The DomainKeys specification was a primary source from which this | |||
specification has been derived. Further information about DomainKeys | specification has been derived. Further information about DomainKeys | |||
is at | is at | |||
<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-04 version | F.1 Changes since -ietf-05 version | |||
The following changes were made between draft-ietf-dkim-base-05 and | ||||
draft-ietf-dkim-base-06: | ||||
o Fix an error in an example in Appendix C. | ||||
o Substantial updates to Appendixes B and D. | ||||
o Clarify ABNF for tag-value. | ||||
o Changed SWSP (streaming white space) to LWSP (linear white space | ||||
from RFC 4234); LWSP makes it clear that white space is required | ||||
after a CRLF. | ||||
o Add normative reference to SHA1/SHA256 FIPS publication 180-2. | ||||
o Several minor edits based on AD Review. | ||||
o Move discussion of not re-using a selector (i.e., changing the | ||||
public key for a single selector) from informational to normative. | ||||
o Assorted wordsmithing based on external review. | ||||
F.2 Changes since -ietf-04 version | ||||
The following changes were made between draft-ietf-dkim-base-04 and | The following changes were made between draft-ietf-dkim-base-04 and | |||
draft-ietf-dkim-base-05: | draft-ietf-dkim-base-05: | |||
o Clarified definition of "plain text" in section 3.2 (issue 1316). | o Clarified definition of "plain text" in section 3.2 (issue 1316). | |||
o Added some clarification about multiple listings of non-existent | o Added some clarification about multiple listings of non-existent | |||
header field names in h= in section 5.4 (issue 1316). | header field names in h= in section 5.4 (issue 1316). | |||
o Finished filling out IANA registries in section 7 (issue 1320). | o Finished filling out IANA registries in section 7 (issue 1320). | |||
skipping to change at page 64, line 45 | skipping to change at page 66, line 29 | |||
o Clarified handling of bare CR and LF in section 5.3 (issue 1326). | o Clarified handling of bare CR and LF in section 5.3 (issue 1326). | |||
o Listed the required tags in section 6.1.1 as an informational note | o Listed the required tags in section 6.1.1 as an informational note | |||
(issue 1330). | (issue 1330). | |||
o Changed IDNA reference from 3492 to 3490 (issue 1331). | o Changed IDNA reference from 3492 to 3490 (issue 1331). | |||
o Changed the reference for WSP to 4234; changed the definition of | o Changed the reference for WSP to 4234; changed the definition of | |||
SWSP to exclude bare CR and LF (issue 1332). | SWSP to exclude bare CR and LF (issue 1332). | |||
F.2 Changes since -ietf-03 version | F.3 Changes since -ietf-03 version | |||
The following changes were made between draft-ietf-dkim-base-03 and | The following changes were made between draft-ietf-dkim-base-03 and | |||
draft-ietf-dkim-base-04: | draft-ietf-dkim-base-04: | |||
o Re-worded Abstract to avoid use of "prove" and "non-repudiation". | o Re-worded Abstract to avoid use of "prove" and "non-repudiation". | |||
o Use dot-atom-text instead of dot-atom to avoid inclusion of CFWS. | o Use dot-atom-text instead of dot-atom to avoid inclusion of CFWS. | |||
o Capitalize Selector throughout. | o Capitalize Selector throughout. | |||
skipping to change at page 66, line 7 | skipping to change at page 67, line 38 | |||
data? | data? | |||
o Deal with "relaxed" body canonicalizations, especially in regard | o Deal with "relaxed" body canonicalizations, especially in regard | |||
to bare CRs and NLs. | to bare CRs and NLs. | |||
o How to handle "*" in g= dot-atom-text (which allows "*" as a | o How to handle "*" in g= dot-atom-text (which allows "*" as a | |||
literal character). | literal character). | |||
o The IANA Considerations need to be completed and cleaned up. | o The IANA Considerations need to be completed and cleaned up. | |||
F.3 Changes since -ietf-02 version | F.4 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 67, line 8 | skipping to change at page 68, line 39 | |||
may contain the content. | may contain the content. | |||
o Use dkim-quoted-printable as the encoding used in z= rather than | o Use dkim-quoted-printable as the encoding used in z= rather than | |||
referring to RFC2045, since they are different. | referring to RFC2045, since they are different. | |||
o Rewrite description of g= tag in the key record. | o Rewrite description of g= tag in the key record. | |||
o Deleted use of Domain in ABNF, which permits address-literals; | o Deleted use of Domain in ABNF, which permits address-literals; | |||
define domain-name to act in stead. | define domain-name to act in stead. | |||
F.4 Changes since -ietf-01 version | F.5 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 67, line 39 | skipping to change at page 69, line 21 | |||
o Change "q=dns" query access method to "q=dnstxt" to emphasize the | o Change "q=dns" query access method to "q=dnstxt" to emphasize the | |||
use of the TXT record. The expectation is that a later extension | use of the TXT record. The expectation is that a later extension | |||
will define "q=dnsdkk" to indicate use of a DKK record. (Per 18 | will define "q=dnsdkk" to indicate use of a DKK record. (Per 18 | |||
May Jabber session.) | May Jabber session.) | |||
o Several typos fixed, including removing a paragraph that implied | o Several typos fixed, including removing a paragraph that implied | |||
that the DKIM-Signature header field should be hashed with the | that the DKIM-Signature header field should be hashed with the | |||
body (it should not). | body (it should not). | |||
F.5 Changes since -ietf-00 version | F.6 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 68, line 18 | skipping to change at page 69, line 45 | |||
o Changed signing algorithm to use separate hash of the body of the | o Changed signing algorithm to use separate hash of the body of the | |||
message; this is represented as the "bh=" tag in the DKIM- | message; this is represented as the "bh=" tag in the DKIM- | |||
Signature header field. | Signature header field. | |||
o Changed "z=" tag so that it need not have the same header field | o Changed "z=" tag so that it need not have the same header field | |||
names as the "h=" tag. | names as the "h=" tag. | |||
o Significant wordsmithing. | o Significant wordsmithing. | |||
F.6 Changes since -allman-01 version | F.7 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.7 Changes since -allman-00 version | F.8 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. 115 change blocks. | ||||
330 lines changed or deleted | 422 lines changed or added | |||
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |