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/