Network Working Group E. Allman
Request for Comments: 4871 Sendmail, Inc.
Obsoletes: 4870 J. Callas
Category: Standards Track PGP Corporation
M. Delany
M. Libbey
Yahoo! Inc
J. Fenton
M. Thomas
Cisco Systems, Inc.
May 2007
DomainKeys Identified Mail (DKIM) Signatures
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email using public-key cryptography and
key server technology to permit verification of the source and
contents of messages by either Mail Transfer Agents (MTAs) or Mail
User Agents (MUAs). The ultimate goal of this framework is to permit
a signing domain to assert responsibility for a message, thus
protecting message signer identity and the integrity of the messages
they convey while retaining the functionality of Internet email as it
is known today. Protection of email identity may assist in the
global control of "spam" and "phishing".
Allman, et al. Standards Track [Page 1]
RFC 4871 DKIM Signatures May 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 5
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 5
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5
2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 6
2.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 7
2.6. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 7
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 10
3.3. Signing and Verification Algorithms . . . . . . . . . . . 11
3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 13
3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 17
3.6. Key Management and Representation . . . . . . . . . . . . 25
3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 29
3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 31
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 32
4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 32
4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 33
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1. Determine Whether the Email Should Be Signed and by
Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2. Select a Private Key and Corresponding Selector
Information . . . . . . . . . . . . . . . . . . . . . . . 35
5.3. Normalize the Message to Prevent Transport Conversions . . 35
5.4. Determine the Header Fields to Sign . . . . . . . . . . . 36
5.5. Recommended Signature Content . . . . . . . . . . . . . . 38
5.6. Compute the Message Hash and Signature . . . . . . . . . . 39
5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 40
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 40
6.1. Extract Signatures from the Message . . . . . . . . . . . 41
6.2. Communicate Verification Results . . . . . . . . . . . . . 46
6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 47
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 48
7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 49
7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 49
7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 50
7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 50
7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 51
7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 51
7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 52
Allman, et al. Standards Track [Page 2]
RFC 4871 DKIM Signatures May 2007
7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 52
8. Security Considerations . . . . . . . . . . . . . . . . . . . 52
8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 52
8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 53
8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 54
8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 54
8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 55
8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 55
8.7. Intentionally Malformed Key Records . . . . . . . . . . . 56
8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 56
8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 56
8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 56
8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 56
8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 56
8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 57
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
9.1. Normative References . . . . . . . . . . . . . . . . . . . 57
9.2. Informative References . . . . . . . . . . . . . . . . . . 58
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 60
A.1. The user composes an email . . . . . . . . . . . . . . . . 60
A.2. The email is signed . . . . . . . . . . . . . . . . . . . 61
A.3. The email signature is verified . . . . . . . . . . . . . 61
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 62
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 63
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 65
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 67
Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 68
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 69
Allman, et al. Standards Track [Page 3]
RFC 4871 DKIM Signatures May 2007
1. Introduction
DomainKeys Identified Mail (DKIM) defines a mechanism by which email
messages can be cryptographically signed, permitting a signing domain
to claim responsibility for the introduction of a message into the
mail stream. Message recipients can verify the signature by querying
the signer's domain directly to retrieve the appropriate public key,
and thereby confirm that the message was attested to by a party in
possession of the private key for the signing domain.
The approach taken by DKIM differs from previous approaches to
message signing (e.g., Secure/Multipurpose Internet Mail Extensions
(S/MIME) [RFC1847], OpenPGP [RFC2440]) in that:
o the message signature is written as a message header field so that
neither human recipients nor existing MUA (Mail User Agent)
software is confused by signature-related content appearing in the
message body;
o there is no dependency on public and private key pairs being
issued by well-known, trusted certificate authorities;
o there is no dependency on the deployment of any new Internet
protocols or services for public key distribution or revocation;
o signature verification failure does not force rejection of the
message;
o no attempt is made to include encryption as part of the mechanism;
o message archiving is not a design goal.
DKIM:
o is compatible with the existing email infrastructure and
transparent to the fullest extent possible;
o requires minimal new infrastructure;
o can be implemented independently of clients in order to reduce
deployment time;
o can be deployed incrementally;
o allows delegation of signing to third parties.
Allman, et al. Standards Track [Page 4]
RFC 4871 DKIM Signatures May 2007
1.1. Signing Identity
DKIM separates the question of the identity of the signer of the
message from the purported author of the message. In particular, a
signature includes the identity of the signer. Verifiers can use the
signing information to decide how they want to process the message.
The signing identity is included as part of the signature header
field.
INFORMATIVE RATIONALE: The signing identity specified by a DKIM
signature is not required to match an address in any particular
header field because of the broad methods of interpretation by
recipient mail systems, including MUAs.
1.2. Scalability
DKIM is designed to support the extreme scalability requirements that
characterize the email identification problem. There are currently
over 70 million domains and a much larger number of individual
addresses. DKIM seeks to preserve the positive aspects of the
current email infrastructure, such as the ability for anyone to
communicate with anyone else without introduction.
1.3. Simple Key Management
DKIM differs from traditional hierarchical public-key systems in that
no Certificate Authority infrastructure is required; the verifier
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 the public keys.
Thus, DKIM currently depends on DNS administration and the security
of the DNS system. DKIM is designed to be extensible to other key
fetching services as they become available.
2. Terminology and Definitions
This section defines terms used in the rest of the document. Syntax
descriptions use the form described in Augmented BNF for Syntax
Specifications [RFC4234].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Allman, et al. Standards Track [Page 5]
RFC 4871 DKIM Signatures May 2007
2.1. Signers
Elements in the mail system that sign messages on behalf of a domain
are referred to as signers. These may be MUAs (Mail User Agents),
MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents), or other
agents such as mailing list exploders. In general, any signer will
be involved in the injection of a message into the message system in
some way. The key issue is that a message must be signed before it
leaves the administrative domain of the signer.
2.2. Verifiers
Elements in the mail system that verify signatures are referred to as
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
user (reader) of the message or some consuming agent such as a
mailing list exploder.
2.3. Whitespace
There are three forms of whitespace:
o WSP represents simple whitespace, i.e., a space or a tab character
(formal definition in [RFC4234]).
o LWSP is linear whitespace, defined as WSP plus CRLF (formal
definition in [RFC4234]).
o FWS is folding whitespace. It allows multiple lines separated by
CRLF followed by at least one whitespace, to be joined.
The formal ABNF for these are (WSP and LWSP are given for information
only):
WSP = SP / HTAB
LWSP = *(WSP / CRLF WSP)
FWS = [*WSP CRLF] 1*WSP
The definition of FWS is identical to that in [RFC2822] except for
the exclusion of obs-FWS.
2.4. Common ABNF Tokens
The following ABNF tokens are used elsewhere in this document:
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ]
base64string = 1*(ALPHA / DIGIT / "+" / "/" / [FWS])
[ "=" [FWS] [ "=" [FWS] ] ]
Allman, et al. Standards Track [Page 6]
RFC 4871 DKIM Signatures May 2007
2.5. Imported ABNF Tokens
The following tokens are imported from other RFCs as noted. Those
RFCs should be considered definitive.
The following tokens are imported from [RFC2821]:
o "Local-part" (implementation warning: this permits quoted strings)
o "sub-domain"
The following tokens are imported from [RFC2822]:
o "field-name" (name of a header field)
o "dot-atom-text" (in the Local-part of an email address)
The following tokens are imported from [RFC2045]:
o "qp-section" (a single line of quoted-printable-encoded text)
o "hex-octet" (a quoted-printable encoded octet)
INFORMATIVE NOTE: Be aware that the ABNF in RFC 2045 does not obey
the rules of RFC 4234 and must be interpreted accordingly,
particularly as regards case folding.
Other tokens not defined herein are imported from [RFC4234]. These
are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF,
etc.
2.6. DKIM-Quoted-Printable
The DKIM-Quoted-Printable encoding syntax resembles that described in
Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded
as an "=" followed by two hexadecimal digits from the alphabet
"0123456789ABCDEF" (no lowercase characters permitted) representing
the hexadecimal-encoded integer value of that character. All control
characters (those with values < %x20), 8-bit characters (values >
%x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon
(";", %x3B) MUST be encoded. Note that all whitespace, including
SPACE, CR, and LF characters, MUST be encoded. After encoding, FWS
MAY be added at arbitrary locations in order to avoid excessively
long lines; such whitespace is NOT part of the value, and MUST be
removed before decoding.
Allman, et al. Standards Track [Page 7]
RFC 4871 DKIM Signatures May 2007
ABNF:
dkim-quoted-printable =
*(FWS / hex-octet / dkim-safe-char)
; hex-octet is from RFC 2045
dkim-safe-char = %x21-3A / %x3C / %x3E-7E
; '!' - ':', '<', '>' - '~'
; Characters not listed as "mail-safe" in
; RFC 2049 are also not recommended.
INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted-
Printable as defined in RFC 2045 in several important ways:
1. Whitespace in the input text, including CR and LF, must be
encoded. RFC 2045 does not require such encoding, and does
not permit encoding of CR or LF characters that are part of a
CRLF line break.
2. Whitespace in the encoded text is ignored. This is to allow
tags encoded using DKIM-Quoted-Printable to be wrapped as
needed. In particular, RFC 2045 requires that line breaks in
the input be represented as physical line breaks; that is not
the case here.
3. The "soft line break" syntax ("=" as the last non-whitespace
character on the line) does not apply.
4. DKIM-Quoted-Printable does not require that encoded lines be
no more than 76 characters long (although there may be other
requirements depending on the context in which the encoded
text is being used).
3. Protocol Elements
Protocol Elements are conceptual parts of the protocol that are not
specific to either signers or verifiers. The protocol descriptions
for signers and verifiers are described in later sections (Signer
Actions (Section 5) and Verifier Actions (Section 6)). NOTE: This
section must be read in the context of those sections.
3.1. Selectors
To support multiple concurrent public keys per signing domain, the
key namespace is subdivided using "selectors". For example,
selectors might indicate the names of office locations (e.g.,
"sanfrancisco", "coolumbeach", and "reykjavik"), the signing date
(e.g., "january2005", "february2005", etc.), or even the individual
user.
Allman, et al. Standards Track [Page 8]
RFC 4871 DKIM Signatures May 2007
Selectors are needed to support some important use cases. For
example:
o Domains that want to delegate signing capability for a specific
address for a given duration to a partner, such as an advertising
provider or other outsourced function.
o Domains that want to allow frequent travelers to send messages
locally without the need to connect with a particular MSA.
o "Affinity" domains (e.g., college alumni associations) that
provide forwarding of incoming mail, but that do not operate a
mail submission agent for outgoing mail.
Periods are allowed in selectors and are component separators. When
keys are retrieved from the DNS, periods in selectors define DNS
label boundaries in a manner similar to the conventional use in
domain names. Selector components might be used to combine dates
with locations, for example, "march2005.reykjavik". In a DNS
implementation, this can be used to allow delegation of a portion of
the selector namespace.
ABNF:
selector = sub-domain *( "." sub-domain )
The number of public keys and corresponding selectors for each domain
is determined by the domain owner. Many domain owners will be
satisfied with just one selector, whereas administratively
distributed organizations may choose to manage disparate selectors
and key pairs in different regions or on different email servers.
Beyond administrative convenience, selectors make it possible to
seamlessly replace public keys on a routine basis. If a domain
wishes to change from using a public key associated with selector
"january2005" to a public key associated with selector
"february2005", it merely makes sure that both public keys are
advertised in the public-key repository concurrently for the
transition period during which email may be in transit prior to
verification. At the start of the transition period, the outbound
email servers are configured to sign with the "february2005" private
key. At the end of the transition period, the "january2005" public
key is removed from the public-key repository.
INFORMATIVE NOTE: A key may also be revoked as described below.
The distinction between revoking and removing a key selector
record is subtle. When phasing out keys as described above, a
signing domain would probably simply remove the key record after
Allman, et al. Standards Track [Page 9]
RFC 4871 DKIM Signatures May 2007
the transition period. However, a signing domain could elect to
revoke the key (but maintain the key record) for a further period.
There is no defined semantic difference between a revoked key and
a removed key.
While some domains may wish to make selector values well known,
others will want to take care not to allocate selector names in a way
that allows harvesting of data by outside parties. For example, if
per-user keys are issued, the domain owner will need to make the
decision as to whether to associate this selector directly with the
user name, or make it some unassociated random value, such as a
fingerprint of the public key.
INFORMATIVE OPERATIONS NOTE: Reusing a selector with a new key
(for example, changing the key associated with a user's name)
makes it impossible to tell the difference between a message that
didn't verify because the key is no longer valid versus a message
that is actually forged. For this reason, signers are ill-advised
to reuse selectors for new keys. A better strategy is to assign
new keys to new selectors.
3.2. Tag=Value Lists
DKIM uses a simple "tag=value" syntax in several contexts, including
in messages and domain signature records.
Values are a series of strings containing either plain text, "base64"
text (as defined in [RFC2045], Section 6.8), "qp-section" (ibid,
Section 6.7), or "dkim-quoted-printable" (as defined in Section 2.6).
The name of the tag will determine the encoding of each value.
Unencoded semicolon (";") characters MUST NOT occur in the tag value,
since that separates tag-specs.
INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" defined
below (as "tag-value") only includes 7-bit characters, an
implementation that wished to anticipate future standards would be
advised not to preclude the use of UTF8-encoded text in tag=value
lists.
Allman, et al. Standards Track [Page 10]
RFC 4871 DKIM Signatures May 2007
Formally, the syntax rules are as follows:
tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ]
tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-name = ALPHA 0*ALNUMPUNC
tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ]
; WSP and FWS prohibited at beginning and end
tval = 1*VALCHAR
VALCHAR = %x21-3A / %x3C-7E
; EXCLAMATION to TILDE except SEMICOLON
ALNUMPUNC = ALPHA / DIGIT / "_"
Note that WSP is allowed anywhere around tags. In particular, any
WSP after the "=" and any WSP before the terminating ";" is not part
of the value; however, WSP inside the value is significant.
Tags MUST be interpreted in a case-sensitive manner. Values MUST be
processed as case sensitive unless the specific tag description of
semantics specifies case insensitivity.
Tags with duplicate names MUST NOT occur within a single tag-list; if
a tag name does occur more than once, the entire tag-list is invalid.
Whitespace within a value MUST be retained unless explicitly excluded
by the specific tag description.
Tag=value pairs that represent the default value MAY be included to
aid legibility.
Unrecognized tags MUST be ignored.
Tags that have an empty value are not the same as omitted tags. An
omitted tag is treated as having the default value; a tag with an
empty value explicitly designates the empty string as the value. For
example, "g=" does not mean "g=*", even though "g=*" is the default
for that tag.
3.3. Signing and Verification Algorithms
DKIM supports multiple digital signature algorithms. Two algorithms
are defined by this specification at this time: rsa-sha1 and rsa-
sha256. The rsa-sha256 algorithm is the default if no algorithm is
specified. Verifiers MUST implement both rsa-sha1 and rsa-sha256.
Signers MUST implement and SHOULD sign using rsa-sha256.
Allman, et al. Standards Track [Page 11]
RFC 4871 DKIM Signatures May 2007
INFORMATIVE NOTE: Although sha256 is strongly encouraged, some
senders of low-security messages (such as routine newsletters) may
prefer to use sha1 because of reduced CPU requirements to compute
a sha1 hash. In general, sha256 should always be used whenever
possible.
3.3.1. The rsa-sha1 Signing Algorithm
The rsa-sha1 Signing Algorithm computes a message hash as described
in Section 3.7 below using SHA-1 [FIPS.180-2.2002] as the hash-alg.
That hash is then signed by the signer using the RSA algorithm
(defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the
signer's private key. The hash MUST NOT be truncated or converted
into any form other than the native binary form before being signed.
The signing algorithm SHOULD use a public exponent of 65537.
3.3.2. The rsa-sha256 Signing Algorithm
The rsa-sha256 Signing Algorithm computes a message hash as described
in Section 3.7 below using SHA-256 [FIPS.180-2.2002] as the hash-alg.
That hash is then signed by the signer using the RSA algorithm
(defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the
signer's private key. The hash MUST NOT be truncated or converted
into any form other than the native binary form before being signed.
3.3.3. Key Sizes
Selecting appropriate key sizes is a trade-off between cost,
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
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
validate signatures with larger keys. Verifier policies may use the
length of the signing key as one metric for determining whether a
signature is acceptable.
Factors that should influence the key size choice include the
following:
o The practical constraint that large (e.g., 4096 bit) keys may not
fit within a 512-byte DNS UDP response packet
o The security constraint that keys smaller than 1024 bits are
subject to off-line attacks
o Larger keys impose higher CPU costs to verify and sign email
Allman, et al. Standards Track [Page 12]
RFC 4871 DKIM Signatures May 2007
o Keys can be replaced on a regular basis, thus their lifetime can
be relatively short
o The security goals of this specification are modest compared to
typical goals of other systems that employ digital signatures
See [RFC3766] for further discussion on 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
Empirical evidence demonstrates that some mail servers and relay
systems modify email in transit, potentially invalidating a
signature. There are two competing perspectives on such
modifications. For most signers, mild modification of email is
immaterial to the authentication status of the email. For such
signers, a canonicalization algorithm that survives modest in-transit
modification is preferred.
Other signers demand that any modification of the email, however
minor, result in a signature verification failure. These signers
prefer a canonicalization algorithm that does not tolerate in-transit
modification of the signed email.
Some signers may be willing to accept modifications to header fields
that are within the bounds of email standards such as [RFC2822], but
are unwilling to accept any modification to the body of messages.
To satisfy all requirements, two canonicalization algorithms are
defined for each of the header and the body: a "simple" algorithm
that tolerates almost no modification and a "relaxed" algorithm that
tolerates common modifications such as whitespace replacement and
header field line rewrapping. A signer MAY specify either algorithm
for header or body when signing an email. If no canonicalization
algorithm is specified by the signer, the "simple" algorithm defaults
for both header and body. Verifiers MUST implement both
canonicalization algorithms. Note that the header and body may use
different canonicalization algorithms. Further canonicalization
algorithms MAY be defined in the future; verifiers MUST ignore any
signatures that use unrecognized canonicalization algorithms.
Canonicalization simply prepares the email for presentation to the
signing or verification algorithm. It MUST NOT change the
Allman, et al. Standards Track [Page 13]
RFC 4871 DKIM Signatures May 2007
transmitted data in any way. Canonicalization of header fields and
body are described below.
NOTE: This section assumes that the message is already in "network
normal" format (text is ASCII encoded, lines are separated with CRLF
characters, etc.). See also Section 5.3 for information about
normalizing the message.
3.4.1. The "simple" Header Canonicalization Algorithm
The "simple" header canonicalization algorithm does not change header
fields in any way. Header fields MUST be presented to the signing or
verification algorithm exactly as they are in the message being
signed or verified. In particular, header field names MUST NOT be
case folded and whitespace MUST NOT be changed.
3.4.2. The "relaxed" Header Canonicalization Algorithm
The "relaxed" header canonicalization algorithm MUST apply the
following steps in order:
o Convert all header field names (not the header field values) to
lowercase. For example, convert "SUBJect: AbC" to "subject: AbC".
o Unfold all header field continuation lines as described in
[RFC2822]; in particular, lines with terminators embedded in
continued header field values (that is, CRLF sequences followed by
WSP) MUST be interpreted without the CRLF. Implementations MUST
NOT remove the CRLF at the end of the header field value.
o Convert all sequences of one or more WSP characters to a single SP
character. WSP characters here include those before and after a
line folding boundary.
o Delete all WSP characters at the end of each unfolded header field
value.
o Delete any WSP characters remaining before and after the colon
separating the header field name from the header field value. The
colon separator MUST be retained.
3.4.3. The "simple" Body Canonicalization Algorithm
The "simple" body canonicalization algorithm ignores all empty lines
at the end of the message body. An empty line is a line of zero
length after removal of the line terminator. If there is no body or
no trailing CRLF on the message body, a CRLF is added. It makes no
Allman, et al. Standards Track [Page 14]
RFC 4871 DKIM Signatures May 2007
other changes to the message body. In more formal terms, the
"simple" body canonicalization algorithm converts "0*CRLF" at the end
of the body to a single "CRLF".
Note that a completely empty or missing body is canonicalized as a
single "CRLF"; that is, the canonicalized length will be 2 octets.
3.4.4. The "relaxed" Body Canonicalization Algorithm
The "relaxed" body canonicalization algorithm:
o Ignores all whitespace at the end of lines. Implementations MUST
NOT remove the CRLF at the end of the line.
o Reduces all sequences of WSP within a line to a single SP
character.
o Ignores all empty lines at the end of the message body. "Empty
line" is defined in Section 3.4.3.
INFORMATIVE NOTE: It should be noted that the relaxed body
canonicalization algorithm may enable certain types of extremely
crude "ASCII Art" attacks where a message may be conveyed by
adjusting the spacing between words. If this is a concern, the
"simple" body canonicalization algorithm should be used instead.
3.4.5. Body Length Limits
A body length count MAY be specified to limit the signature
calculation to an initial prefix of the body text, measured in
octets. If the body length count is not specified, the entire
message body is signed.
INFORMATIVE RATIONALE: This capability is provided because it is
very common for mailing lists to add trailers to messages (e.g.,
instructions how to get off the list). Until those messages are
also signed, the body length count is a useful tool for the
verifier since it may as a matter of policy accept messages having
valid signatures with extraneous data.
INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables
an attack in which an attacker modifies a message to include
content that solely benefits the attacker. It is possible for the
appended content to completely replace the original content in the
end recipient's eyes and to defeat duplicate message detection
algorithms. To avoid this attack, signers should be wary of using
Allman, et al. Standards Track [Page 15]
RFC 4871 DKIM Signatures May 2007
this tag, and verifiers might wish to ignore the tag or remove
text that appears after the specified content length, perhaps
based on other criteria.
The body length count allows the signer of a message to permit data
to be appended to the end of the body of a signed message. The body
length count MUST be calculated following the canonicalization
algorithm; for example, any whitespace ignored by a canonicalization
algorithm is not included as part of the body length count. Signers
of MIME messages that include a body length count SHOULD be sure that
the length extends to the closing MIME boundary string.
INFORMATIVE IMPLEMENTATION NOTE: A signer wishing to ensure that
the only acceptable modifications are to add to the MIME postlude
would use a body length count encompassing the entire final MIME
boundary string, including the final "--CRLF". A signer wishing
to allow additional MIME parts but not modification of existing
parts would use a body length count extending through the final
MIME boundary string, omitting the final "--CRLF". Note that this
only works for some MIME types, e.g., multipart/mixed but not
multipart/signed.
A body length count of zero means that the body is completely
unsigned.
Signers wishing to ensure that no modification of any sort can occur
should specify the "simple" canonicalization algorithm for both
header and body and omit the body length count.
3.4.6. Canonicalization Examples (INFORMATIVE)
In the following examples, actual whitespace is used only for
clarity. The actual input and output text is designated using
bracketed descriptors: "<sp>" for a space character, "<htab>" for a </htab></sp>
tab character, and "<crlf>" for a carriage-return/line-feed sequence. </crlf>
For example, "X <sp> Y" and "X<sp>Y" represent the same three </sp></sp>
characters.
Example 1: A message reading:
A: <sp> X <crlf></crlf></sp>
B <sp> : <sp> Y <htab><crlf></crlf></htab></sp></sp>
<htab> Z <sp><sp><crlf></crlf></sp></sp></htab>
<crlf></crlf>
<sp> C <sp><crlf></crlf></sp></sp>
D <sp><htab><sp> E <crlf></crlf></sp></htab></sp>
<crlf></crlf>
<crlf></crlf>
Allman, et al. Standards Track [Page 16]
RFC 4871 DKIM Signatures May 2007
when canonicalized using relaxed canonicalization for both header and
body results in a header reading:
a:X <crlf></crlf>
b:Y <sp> Z <crlf></crlf></sp>
and a body reading:
<sp> C <crlf></crlf></sp>
D <sp> E <crlf></crlf></sp>
Example 2: The same message canonicalized using simple
canonicalization for both header and body results in a header
reading:
A: <sp> X <crlf></crlf></sp>
B <sp> : <sp> Y <htab><crlf></crlf></htab></sp></sp>
<htab> Z <sp><sp><crlf></crlf></sp></sp></htab>
and a body reading:
<sp> C <sp><crlf></crlf></sp></sp>
D <sp><htab><sp> E <crlf></crlf></sp></htab></sp>
Example 3: When processed using relaxed header canonicalization and
simple body canonicalization, the canonicalized version has a header
of:
a:X <crlf></crlf>
b:Y <sp> Z <crlf></crlf></sp>
and a body reading:
<sp> C <sp><crlf></crlf></sp></sp>
D <sp><htab><sp> E <crlf></crlf></sp></htab></sp>
3.5. The DKIM-Signature Header Field
The signature of the email is stored in the DKIM-Signature header
field. This header field contains all of the signature and key-
fetching data. The DKIM-Signature value is a tag-list as described
in Section 3.2.
The DKIM-Signature header field SHOULD be treated as though it were a
trace header field as defined in Section 3.6 of [RFC2822], and hence
SHOULD NOT be reordered and SHOULD be prepended to the message.
Allman, et al. Standards Track [Page 17]
RFC 4871 DKIM Signatures May 2007
The DKIM-Signature header field being created or verified is always
included in the signature calculation, after the rest of the header
fields being signed; however, when calculating or verifying the
signature, the value of the "b=" tag (signature value) of that DKIM-
Signature header field MUST be treated as though it were an empty
string. Unknown tags in the DKIM-Signature header field MUST be
included in the signature calculation but MUST be otherwise ignored
by verifiers. Other DKIM-Signature header fields that are included
in the signature should be treated as normal header fields; in
particular, the "b=" tag is not treated specially.
The encodings for each field type are listed below. Tags described
as qp-section are encoded as described in Section 6.7 of MIME Part
One [RFC2045], with the additional conversion of semicolon characters
to "=3B"; intuitively, this is one line of quoted-printable encoded
text. The dkim-quoted-printable syntax is defined in Section 2.6.
Tags on the DKIM-Signature header field along with their type and
requirement status are shown below. Unrecognized tags MUST be
ignored.
v= Version (MUST be included). This tag defines the version of this
specification that applies to the signature record. It MUST have
the value "1". Note that verifiers must do a string comparison
on this value; for example, "1" is not the same as "1.0".
ABNF:
sig-v-tag = %x76 [FWS] "=" [FWS] "1"
INFORMATIVE NOTE: DKIM-Signature version numbers are expected
to increase arithmetically as new versions of this
specification are released.
a= The algorithm used to generate the signature (plain-text;
REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256";
signers SHOULD sign using "rsa-sha256". See Section 3.3 for a
description of algorithms.
ABNF:
sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg
sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h
sig-a-tag-k = "rsa" / x-sig-a-tag-k
sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h
x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) ; for later extension
x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) ; for later extension
Allman, et al. Standards Track [Page 18]
RFC 4871 DKIM Signatures May 2007
b= The signature data (base64; REQUIRED). Whitespace is ignored in
this value and MUST be ignored when reassembling the original
signature. In particular, the signing process can safely insert
FWS in this value in arbitrary places to conform to line-length
limits. See Signer Actions (Section 5) for how the signature is
computed.
ABNF:
sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data
sig-b-tag-data = base64string
bh= The hash of the canonicalized body part of the message as limited
by the "l=" tag (base64; REQUIRED). Whitespace is ignored in
this value and MUST be ignored when reassembling the original
signature. In particular, the signing process can safely insert
FWS in this value in arbitrary places to conform to line-length
limits. See Section 3.7 for how the body hash is computed.
ABNF:
sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data
sig-bh-tag-data = base64string
c= Message canonicalization (plain-text; OPTIONAL, default is
"simple/simple"). This tag informs the verifier of the type of
canonicalization used to prepare the message for signing. It
consists of two names separated by a "slash" (%d47) character,
corresponding to the header and body canonicalization algorithms
respectively. These algorithms are described in Section 3.4. If
only one algorithm is named, that algorithm is used for the
header and "simple" is used for the body. For example,
"c=relaxed" is treated the same as "c=relaxed/simple".
ABNF:
sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg
["/" sig-c-tag-alg]
sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg
x-sig-c-tag-alg = hyphenated-word ; for later extension
d= The domain of the signing entity (plain-text; REQUIRED). This is
the domain that will be queried for the public key. This domain
MUST be the same as or a parent domain of the "i=" tag (the
signing identity, as described below), or it MUST meet the
requirements for parent domain signing described in Section 3.8.
When presented with a signature that does not meet these
requirement, verifiers MUST consider the signature invalid.
Allman, et al. Standards Track [Page 19]
RFC 4871 DKIM Signatures May 2007
Internationalized domain names MUST be encoded as described in
[RFC3490].
ABNF:
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain)
; from RFC 2821 Domain, but excluding address-literal
h= Signed header fields (plain-text, but see description; REQUIRED).
A colon-separated list of header field names that identify the
header fields presented to the signing algorithm. The field MUST
contain the complete list of header fields in the order presented
to the signing algorithm. The field MAY contain names of header
fields that do not exist when signed; nonexistent header fields
do not contribute to the signature computation (that is, they are
treated as the null input, including the header field name, the
separating colon, the header field value, and any CRLF
terminator). The field MUST NOT include the DKIM-Signature
header field that is being created or verified, but may include
others. Folding whitespace (FWS) MAY be included on either side
of the colon separator. Header field names MUST be compared
against actual header field names in a case-insensitive manner.
This list MUST NOT be empty. See Section 5.4 for a discussion of
choosing header fields to sign.
ABNF:
sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name
0*( *FWS ":" *FWS hdr-name )
hdr-name = field-name
INFORMATIVE EXPLANATION: By "signing" header fields that do not
actually exist, a signer can prevent insertion of those
header fields before verification. However, since a signer
cannot possibly know what header fields might be created in
the future, and that some MUAs might present header fields
that are embedded inside a message (e.g., as a message/rfc822
content type), the security of this solution is not total.
INFORMATIVE EXPLANATION: The exclusion of the header field name
and colon as well as the header field value for non-existent
header fields prevents an attacker from inserting an actual
header field with a null value.
Allman, et al. Standards Track [Page 20]
RFC 4871 DKIM Signatures May 2007
i= Identity of the user or agent (e.g., a mailing list manager) on
behalf of which this message is signed (dkim-quoted-printable;
OPTIONAL, default is an empty Local-part followed by an "@"
followed by the domain from the "d=" tag). The syntax is a
standard email address where the Local-part MAY be omitted. The
domain part of the address MUST be the same as or a subdomain of
the value of the "d=" tag.
Internationalized domain names MUST be converted using the steps
listed in Section 4 of [RFC3490] using the "ToASCII" function.
ABNF:
sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" domain-name
INFORMATIVE NOTE: The Local-part of the "i=" tag is optional
because in some cases a signer may not be able to establish a
verified individual identity. In such cases, the signer may
wish to assert that although it is willing to go as far as
signing for the domain, it is unable or unwilling to commit
to an individual user name within their domain. It can do so
by including the domain part but not the Local-part of the
identity.
INFORMATIVE DISCUSSION: This document does not require the value
of the "i=" tag to match the identity in any message header
fields. This is considered to be a verifier policy issue.
Constraints between the value of the "i=" tag and other
identities in other header fields seek to apply basic
authentication into the semantics of trust associated with a
role such as content author. Trust is a broad and complex
topic and trust mechanisms are subject to highly creative
attacks. The real-world efficacy of any but the most basic
bindings between the "i=" value and other identities is not
well established, nor is its vulnerability to subversion by
an attacker. Hence reliance on the use of these options
should be strictly limited. In particular, it is not at all
clear to what extent a typical end-user recipient can rely on
any assurances that might be made by successful use of the
"i=" options.
l= Body length count (plain-text unsigned decimal integer; OPTIONAL,
default is entire body). This tag informs the verifier of the
number of octets in the body of the email after canonicalization
included in the cryptographic hash, starting from 0 immediately
following the CRLF preceding the body. This value MUST NOT be
larger than the actual number of octets in the canonicalized
message body.
Allman, et al. Standards Track [Page 21]
RFC 4871 DKIM Signatures May 2007
INFORMATIVE IMPLEMENTATION WARNING: Use of the "l=" tag might
allow display of fraudulent content without appropriate
warning to end users. The "l=" tag is intended for
increasing signature robustness when sending to mailing lists
that both modify their content and do not sign their
messages. However, using the "l=" tag enables attacks in
which an intermediary with malicious intent modifies a
message to include content that solely benefits the attacker.
It is possible for the appended content to completely replace
the original content in the end recipient's eyes and to
defeat duplicate message detection algorithms. Examples are
described in Security Considerations (Section 8). To avoid
this attack, signers should be extremely wary of using this
tag, and verifiers might wish to ignore the tag or remove
text that appears after the specified content length.
INFORMATIVE NOTE: The value of the "l=" tag is constrained to 76
decimal digits. This constraint is not intended to predict
the size of future messages or to require implementations to
use an integer representation large enough to represent the
maximum possible value, but is intended to remind the
implementer to check the length of this and all other tags
during verification and to test for integer overflow when
decoding the value. Implementers may need to limit the
actual value expressed to a value smaller than 10^76, e.g.,
to allow a message to fit within the available storage space.
ABNF:
sig-l-tag = %x6c [FWS] "=" [FWS] 1*76DIGIT
q= A colon-separated list of query methods used to retrieve the
public key (plain-text; OPTIONAL, default is "dns/txt"). Each
query method is of the form "type[/options]", where the syntax
and semantics of the options depend on the type and specified
options. If there are multiple query mechanisms listed, the
choice of query mechanism MUST NOT change the interpretation of
the signature. Implementations MUST use the recognized query
mechanisms in the order presented.
Currently, the only valid value is "dns/txt", which defines the DNS
TXT record lookup algorithm described elsewhere in this document.
The only option defined for the "dns" query type is "txt", which
MUST be included. Verifiers and signers MUST support "dns/txt".
Allman, et al. Standards Track [Page 22]
RFC 4871 DKIM Signatures May 2007
ABNF:
sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method
*([FWS] ":" [FWS] sig-q-tag-method)
sig-q-tag-method = "dns/txt" / x-sig-q-tag-type
["/" x-sig-q-tag-args]
x-sig-q-tag-type = hyphenated-word ; for future extension
x-sig-q-tag-args = qp-hdr-value
s= The selector subdividing the namespace for the "d=" (domain) tag
(plain-text; REQUIRED).
ABNF:
sig-s-tag = %x73 [FWS] "=" [FWS] selector
t= Signature Timestamp (plain-text unsigned decimal integer;
RECOMMENDED, default is an unknown creation time). The time that
this signature was created. The format is the number of seconds
since 00:00:00 on January 1, 1970 in the UTC time zone. The
value is expressed as an unsigned integer in decimal ASCII. This
value is not constrained to fit into a 31- or 32-bit integer.
Implementations SHOULD be prepared to handle values up to at
least 10^12 (until approximately AD 200,000; this fits into 40
bits). To avoid denial-of-service attacks, implementations MAY
consider any value longer than 12 digits to be infinite. Leap
seconds are not counted. Implementations MAY ignore signatures
that have a timestamp in the future.
ABNF:
sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT
x= Signature Expiration (plain-text unsigned decimal integer;
RECOMMENDED, default is no expiration). The format is the same
as in the "t=" tag, represented as an absolute date, not as a
time delta from the signing timestamp. The value is expressed as
an unsigned integer in decimal ASCII, with the same constraints
on the value in the "t=" tag. Signatures MAY be considered
invalid if the verification time at the verifier is past the
expiration date. The verification time should be the time that
the message was first received at the administrative domain of
the verifier if that time is reliably available; otherwise the
current time should be used. The value of the "x=" tag MUST be
greater than the value of the "t=" tag if both are present.
Allman, et al. Standards Track [Page 23]
RFC 4871 DKIM Signatures May 2007
INFORMATIVE NOTE: The "x=" tag is not intended as an anti-replay
defense.
ABNF:
sig-x-tag = %x78 [FWS] "=" [FWS] 1*12DIGIT
z= Copied header fields (dkim-quoted-printable, but see description;
OPTIONAL, default is null). A vertical-bar-separated list of
selected header fields present when the message was signed,
including both the field name and value. It is not required to
include all header fields present at the time of signing. This
field need not contain the same header fields listed in the "h="
tag. The header field text itself must encode the vertical bar
("|", %x7C) character (i.e., vertical bars in the "z=" text are
metacharacters, and any actual vertical bar characters in a
copied header field must be encoded). Note that all whitespace
must be encoded, including whitespace between the colon and the
header field value. After encoding, FWS MAY be added at
arbitrary locations in order to avoid excessively long lines;
such whitespace is NOT part of the value of the header field, and
MUST be removed before decoding.
The header fields referenced by the "h=" tag refer to the fields in
the RFC 2822 header of the message, not to any copied fields in
the "z=" tag. Copied header field values are for diagnostic use.
Header fields with characters requiring conversion (perhaps from
legacy MTAs that are not [RFC2822] compliant) SHOULD be converted
as described in MIME Part Three [RFC2047].
ABNF:
sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy
*( [FWS] "|" sig-z-tag-copy )
sig-z-tag-copy = hdr-name ":" qp-hdr-value
qp-hdr-value = dkim-quoted-printable ; with "|" encoded
INFORMATIVE EXAMPLE of a signature header field spread across
multiple continuation lines:
Allman, et al. Standards Track [Page 24]
RFC 4871 DKIM Signatures May 2007
DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane;
c=simple; q=dns/txt; i=@eng.example.net;
t=1117574938; x=1118006938;
h=from:to:subject:date;
z=From:foo@eng.example.net|To:joe@example.com|
Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR
3.6. Key Management and Representation
Signature applications require some level of assurance that the
verification public key is associated with the claimed signer. Many
applications achieve this by using public key certificates issued by
a trusted third party. However, DKIM can achieve a sufficient level
of security, with significantly enhanced scalability, by simply
having the verifier query the purported signer's DNS entry (or some
security-equivalent) in order to retrieve the public key.
DKIM keys can potentially be stored in multiple types of key servers
and in multiple formats. The storage and format of keys are
irrelevant to the remainder of the DKIM algorithm.
Parameters to the key lookup algorithm are the type of the lookup
(the "q=" tag), the domain of the signer (the "d=" tag of the DKIM-
Signature header field), and the selector (the "s=" tag).
public_key = dkim_find_key(q_val, d_val, s_val)
This document defines a single binding, using DNS TXT records to
distribute the keys. Other bindings may be defined in the future.
3.6.1. Textual Representation
It is expected that many key servers will choose to present the keys
in an otherwise unstructured text format (for example, an XML form
would not be considered to be unstructured text for this purpose).
The following definition MUST be used for any DKIM key represented in
an otherwise unstructured textual form.
The overall syntax is a tag-list as described in Section 3.2. The
current valid tags are described below. Other tags MAY be present
and MUST be ignored by any implementation that does not understand
them.
Allman, et al. Standards Track [Page 25]
RFC 4871 DKIM Signatures May 2007
v= Version of the DKIM key record (plain-text; RECOMMENDED, default
is "DKIM1"). If specified, this tag MUST be set
<PRE>
Network Working Group E. Allman
Request for Comments: 4871 Sendmail, Inc.
Obsoletes: 4870 J. Callas
Category: Standards Track PGP Corporation
M. Delany
M. Libbey
Yahoo! Inc
J. Fenton
M. Thomas
Cisco Systems, Inc.
May 2007
DomainKeys Identified Mail (DKIM) Signatures
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email using public-key cryptography and
key server technology to permit verification of the source and
contents of messages by either Mail Transfer Agents (MTAs) or Mail
User Agents (MUAs). The ultimate goal of this framework is to permit
a signing domain to assert responsibility for a message, thus
protecting message signer identity and the integrity of the messages
they convey while retaining the functionality of Internet email as it
is known today. Protection of email identity may assist in the
global control of "spam" and "phishing".
Allman, et al. Standards Track [Page 1]
RFC 4871 DKIM Signatures May 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 5
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 5
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5
2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 6
2.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 7
2.6. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 7
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 10
3.3. Signing and Verification Algorithms . . . . . . . . . . . 11
3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 13
3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 17
3.6. Key Management and Representation . . . . . . . . . . . . 25
3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 29
3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 31
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 32
4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 32
4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 33
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1. Determine Whether the Email Should Be Signed and by
Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2. Select a Private Key and Corresponding Selector
Information . . . . . . . . . . . . . . . . . . . . . . . 35
5.3. Normalize the Message to Prevent Transport Conversions . . 35
5.4. Determine the Header Fields to Sign . . . . . . . . . . . 36
5.5. Recommended Signature Content . . . . . . . . . . . . . . 38
5.6. Compute the Message Hash and Signature . . . . . . . . . . 39
5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 40
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 40
6.1. Extract Signatures from the Message . . . . . . . . . . . 41
6.2. Communicate Verification Results . . . . . . . . . . . . . 46
6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 47
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 48
7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 49
7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 49
7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 50
7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 50
7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 51
7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 51
7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 52
Allman, et al. Standards Track [Page 2]
RFC 4871 DKIM Signatures May 2007
7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 52
8. Security Considerations . . . . . . . . . . . . . . . . . . . 52
8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 52
8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 53
8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 54
8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 54
8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 55
8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 55
8.7. Intentionally Malformed Key Records . . . . . . . . . . . 56
8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 56
8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 56
8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 56
8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 56
8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 56
8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 57
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
9.1. Normative References . . . . . . . . . . . . . . . . . . . 57
9.2. Informative References . . . . . . . . . . . . . . . . . . 58
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 60
A.1. The user composes an email . . . . . . . . . . . . . . . . 60
A.2. The email is signed . . . . . . . . . . . . . . . . . . . 61
A.3. The email signature is verified . . . . . . . . . . . . . 61
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 62
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 63
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 65
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 67
Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 68
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 69
Allman, et al. Standards Track [Page 3]
RFC 4871 DKIM Signatures May 2007
1. Introduction
DomainKeys Identified Mail (DKIM) defines a mechanism by which email
messages can be cryptographically signed, permitting a signing domain
to claim responsibility for the introduction of a message into the
mail stream. Message recipients can verify the signature by querying
the signer's domain directly to retrieve the appropriate public key,
and thereby confirm that the message was attested to by a party in
possession of the private key for the signing domain.
The approach taken by DKIM differs from previous approaches to
message signing (e.g., Secure/Multipurpose Internet Mail Extensions
(S/MIME) [RFC1847], OpenPGP [RFC2440]) in that:
o the message signature is written as a message header field so that
neither human recipients nor existing MUA (Mail User Agent)
software is confused by signature-related content appearing in the
message body;
o there is no dependency on public and private key pairs being
issued by well-known, trusted certificate authorities;
o there is no dependency on the deployment of any new Internet
protocols or services for public key distribution or revocation;
o signature verification failure does not force rejection of the
message;
o no attempt is made to include encryption as part of the mechanism;
o message archiving is not a design goal.
DKIM:
o is compatible with the existing email infrastructure and
transparent to the fullest extent possible;
o requires minimal new infrastructure;
o can be implemented independently of clients in order to reduce
deployment time;
o can be deployed incrementally;
o allows delegation of signing to third parties.
Allman, et al. Standards Track [Page 4]
RFC 4871 DKIM Signatures May 2007
1.1. Signing Identity
DKIM separates the question of the identity of the signer of the
message from the purported author of the message. In particular, a
signature includes the identity of the signer. Verifiers can use the
signing information to decide how they want to process the message.
The signing identity is included as part of the signature header
field.
INFORMATIVE RATIONALE: The signing identity specified by a DKIM
signature is not required to match an address in any particular
header field because of the broad methods of interpretation by
recipient mail systems, including MUAs.
1.2. Scalability
DKIM is designed to support the extreme scalability requirements that
characterize the email identification problem. There are currently
over 70 million domains and a much larger number of individual
addresses. DKIM seeks to preserve the positive aspects of the
current email infrastructure, such as the ability for anyone to
communicate with anyone else without introduction.
1.3. Simple Key Management
DKIM differs from traditional hierarchical public-key systems in that
no Certificate Authority infrastructure is required; the verifier
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 the public keys.
Thus, DKIM currently depends on DNS administration and the security
of the DNS system. DKIM is designed to be extensible to other key
fetching services as they become available.
2. Terminology and Definitions
This section defines terms used in the rest of the document. Syntax
descriptions use the form described in Augmented BNF for Syntax
Specifications [RFC4234].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Allman, et al. Standards Track [Page 5]
RFC 4871 DKIM Signatures May 2007
2.1. Signers
Elements in the mail system that sign messages on behalf of a domain
are referred to as signers. These may be MUAs (Mail User Agents),
MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents), or other
agents such as mailing list exploders. In general, any signer will
be involved in the injection of a message into the message system in
some way. The key issue is that a message must be signed before it
leaves the administrative domain of the signer.
2.2. Verifiers
Elements in the mail system that verify signatures are referred to as
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
user (reader) of the message or some consuming agent such as a
mailing list exploder.
2.3. Whitespace
There are three forms of whitespace:
o WSP represents simple whitespace, i.e., a space or a tab character
(formal definition in [RFC4234]).
o LWSP is linear whitespace, defined as WSP plus CRLF (formal
definition in [RFC4234]).
o FWS is folding whitespace. It allows multiple lines separated by
CRLF followed by at least one whitespace, to be joined.
The formal ABNF for these are (WSP and LWSP are given for information
only):
WSP = SP / HTAB
LWSP = *(WSP / CRLF WSP)
FWS = [*WSP CRLF] 1*WSP
The definition of FWS is identical to that in [RFC2822] except for
the exclusion of obs-FWS.
2.4. Common ABNF Tokens
The following ABNF tokens are used elsewhere in this document:
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ]
base64string = 1*(ALPHA / DIGIT / "+" / "/" / [FWS])
[ "=" [FWS] [ "=" [FWS] ] ]
Allman, et al. Standards Track [Page 6]
RFC 4871 DKIM Signatures May 2007
2.5. Imported ABNF Tokens
The following tokens are imported from other RFCs as noted. Those
RFCs should be considered definitive.
The following tokens are imported from [RFC2821]:
o "Local-part" (implementation warning: this permits quoted strings)
o "sub-domain"
The following tokens are imported from [RFC2822]:
o "field-name" (name of a header field)
o "dot-atom-text" (in the Local-part of an email address)
The following tokens are imported from [RFC2045]:
o "qp-section" (a single line of quoted-printable-encoded text)
o "hex-octet" (a quoted-printable encoded octet)
INFORMATIVE NOTE: Be aware that the ABNF in RFC 2045 does not obey
the rules of RFC 4234 and must be interpreted accordingly,
particularly as regards case folding.
Other tokens not defined herein are imported from [RFC4234]. These
are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF,
etc.
2.6. DKIM-Quoted-Printable
The DKIM-Quoted-Printable encoding syntax resembles that described in
Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded
as an "=" followed by two hexadecimal digits from the alphabet
"0123456789ABCDEF" (no lowercase characters permitted) representing
the hexadecimal-encoded integer value of that character. All control
characters (those with values &lt; %x20), 8-bit characters (values &gt;
%x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon
(";", %x3B) MUST be encoded. Note that all whitespace, including
SPACE, CR, and LF characters, MUST be encoded. After encoding, FWS
MAY be added at arbitrary locations in order to avoid excessively
long lines; such whitespace is NOT part of the value, and MUST be
removed before decoding.
Allman, et al. Standards Track [Page 7]
RFC 4871 DKIM Signatures May 2007
ABNF:
dkim-quoted-printable =
*(FWS / hex-octet / dkim-safe-char)
; hex-octet is from RFC 2045
dkim-safe-char = %x21-3A / %x3C / %x3E-7E
; '!' - ':', '&lt;', '&gt;' - '~'
; Characters not listed as "mail-safe" in
; RFC 2049 are also not recommended.
INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted-
Printable as defined in RFC 2045 in several important ways:
1. Whitespace in the input text, including CR and LF, must be
encoded. RFC 2045 does not require such encoding, and does
not permit encoding of CR or LF characters that are part of a
CRLF line break.
2. Whitespace in the encoded text is ignored. This is to allow
tags encoded using DKIM-Quoted-Printable to be wrapped as
needed. In particular, RFC 2045 requires that line breaks in
the input be represented as physical line breaks; that is not
the case here.
3. The "soft line break" syntax ("=" as the last non-whitespace
character on the line) does not apply.
4. DKIM-Quoted-Printable does not require that encoded lines be
no more than 76 characters long (although there may be other
requirements depending on the context in which the encoded
text is being used).
3. Protocol Elements
Protocol Elements are conceptual parts of the protocol that are not
specific to either signers or verifiers. The protocol descriptions
for signers and verifiers are described in later sections (Signer
Actions (Section 5) and Verifier Actions (Section 6)). NOTE: This
section must be read in the context of those sections.
3.1. Selectors
To support multiple concurrent public keys per signing domain, the
key namespace is subdivided using "selectors". For example,
selectors might indicate the names of office locations (e.g.,
"sanfrancisco", "coolumbeach", and "reykjavik"), the signing date
(e.g., "january2005", "february2005", etc.), or even the individual
user.
Allman, et al. Standards Track [Page 8]
RFC 4871 DKIM Signatures May 2007
Selectors are needed to support some important use cases. For
example:
o Domains that want to delegate signing capability for a specific
address for a given duration to a partner, such as an advertising
provider or other outsourced function.
o Domains that want to allow frequent travelers to send messages
locally without the need to connect with a particular MSA.
o "Affinity" domains (e.g., college alumni associations) that
provide forwarding of incoming mail, but that do not operate a
mail submission agent for outgoing mail.
Periods are allowed in selectors and are component separators. When
keys are retrieved from the DNS, periods in selectors define DNS
label boundaries in a manner similar to the conventional use in
domain names. Selector components might be used to combine dates
with locations, for example, "march2005.reykjavik". In a DNS
implementation, this can be used to allow delegation of a portion of
the selector namespace.
ABNF:
selector = sub-domain *( "." sub-domain )
The number of public keys and corresponding selectors for each domain
is determined by the domain owner. Many domain owners will be
satisfied with just one selector, whereas administratively
distributed organizations may choose to manage disparate selectors
and key pairs in different regions or on different email servers.
Beyond administrative convenience, selectors make it possible to
seamlessly replace public keys on a routine basis. If a domain
wishes to change from using a public key associated with selector
"january2005" to a public key associated with selector
"february2005", it merely makes sure that both public keys are
advertised in the public-key repository concurrently for the
transition period during which email may be in transit prior to
verification. At the start of the transition period, the outbound
email servers are configured to sign with the "february2005" private
key. At the end of the transition period, the "january2005" public
key is removed from the public-key repository.
INFORMATIVE NOTE: A key may also be revoked as described below.
The distinction between revoking and removing a key selector
record is subtle. When phasing out keys as described above, a
signing domain would probably simply remove the key record after
Allman, et al. Standards Track [Page 9]
RFC 4871 DKIM Signatures May 2007
the transition period. However, a signing domain could elect to
revoke the key (but maintain the key record) for a further period.
There is no defined semantic difference between a revoked key and
a removed key.
While some domains may wish to make selector values well known,
others will want to take care not to allocate selector names in a way
that allows harvesting of data by outside parties. For example, if
per-user keys are issued, the domain owner will need to make the
decision as to whether to associate this selector directly with the
user name, or make it some unassociated random value, such as a
fingerprint of the public key.
INFORMATIVE OPERATIONS NOTE: Reusing a selector with a new key
(for example, changing the key associated with a user's name)
makes it impossible to tell the difference between a message that
didn't verify because the key is no longer valid versus a message
that is actually forged. For this reason, signers are ill-advised
to reuse selectors for new keys. A better strategy is to assign
new keys to new selectors.
3.2. Tag=Value Lists
DKIM uses a simple "tag=value" syntax in several contexts, including
in messages and domain signature records.
Values are a series of strings containing either plain text, "base64"
text (as defined in [RFC2045], Section 6.8), "qp-section" (ibid,
Section 6.7), or "dkim-quoted-printable" (as defined in Section 2.6).
The name of the tag will determine the encoding of each value.
Unencoded semicolon (";") characters MUST NOT occur in the tag value,
since that separates tag-specs.
INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" defined
below (as "tag-value") only includes 7-bit characters, an
implementation that wished to anticipate future standards would be
advised not to preclude the use of UTF8-encoded text in tag=value
lists.
Allman, et al. Standards Track [Page 10]
RFC 4871 DKIM Signatures May 2007
Formally, the syntax rules are as follows:
tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ]
tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-name = ALPHA 0*ALNUMPUNC
tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ]
; WSP and FWS prohibited at beginning and end
tval = 1*VALCHAR
VALCHAR = %x21-3A / %x3C-7E
; EXCLAMATION to TILDE except SEMICOLON
ALNUMPUNC = ALPHA / DIGIT / "_"
Note that WSP is allowed anywhere around tags. In particular, any
WSP after the "=" and any WSP before the terminating ";" is not part
of the value; however, WSP inside the value is significant.
Tags MUST be interpreted in a case-sensitive manner. Values MUST be
processed as case sensitive unless the specific tag description of
semantics specifies case insensitivity.
Tags with duplicate names MUST NOT occur within a single tag-list; if
a tag name does occur more than once, the entire tag-list is invalid.
Whitespace within a value MUST be retained unless explicitly excluded
by the specific tag description.
Tag=value pairs that represent the default value MAY be included to
aid legibility.
Unrecognized tags MUST be ignored.
Tags that have an empty value are not the same as omitted tags. An
omitted tag is treated as having the default value; a tag with an
empty value explicitly designates the empty string as the value. For
example, "g=" does not mean "g=*", even though "g=*" is the default
for that tag.
3.3. Signing and Verification Algorithms
DKIM supports multiple digital signature algorithms. Two algorithms
are defined by this specification at this time: rsa-sha1 and rsa-
sha256. The rsa-sha256 algorithm is the default if no algorithm is
specified. Verifiers MUST implement both rsa-sha1 and rsa-sha256.
Signers MUST implement and SHOULD sign using rsa-sha256.
Allman, et al. Standards Track [Page 11]
RFC 4871 DKIM Signatures May 2007
INFORMATIVE NOTE: Although sha256 is strongly encouraged, some
senders of low-security messages (such as routine newsletters) may
prefer to use sha1 because of reduced CPU requirements to compute
a sha1 hash. In general, sha256 should always be used whenever
possible.
3.3.1. The rsa-sha1 Signing Algorithm
The rsa-sha1 Signing Algorithm computes a message hash as described
in Section 3.7 below using SHA-1 [FIPS.180-2.2002] as the hash-alg.
That hash is then signed by the signer using the RSA algorithm
(defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the
signer's private key. The hash MUST NOT be truncated or converted
into any form other than the native binary form before being signed.
The signing algorithm SHOULD use a public exponent of 65537.
3.3.2. The rsa-sha256 Signing Algorithm
The rsa-sha256 Signing Algorithm computes a message hash as described
in Section 3.7 below using SHA-256 [FIPS.180-2.2002] as the hash-alg.
That hash is then signed by the signer using the RSA algorithm
(defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the
signer's private key. The hash MUST NOT be truncated or converted
into any form other than the native binary form before being signed.
3.3.3. Key Sizes
Selecting appropriate key sizes is a trade-off between cost,
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
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
validate signatures with larger keys. Verifier policies may use the
length of the signing key as one metric for determining whether a
signature is acceptable.
Factors that should influence the key size choice include the
following:
o The practical constraint that large (e.g., 4096 bit) keys may not
fit within a 512-byte DNS UDP response packet
o The security constraint that keys smaller than 1024 bits are
subject to off-line attacks
o Larger keys impose higher CPU costs to verify and sign email
Allman, et al. Standards Track [Page 12]
RFC 4871 DKIM Signatures May 2007
o Keys can be replaced on a regular basis, thus their lifetime can
be relatively short
o The security goals of this specification are modest compared to
typical goals of other systems that employ digital signatures
See [RFC3766] for further discussion on 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
Empirical evidence demonstrates that some mail servers and relay
systems modify email in transit, potentially invalidating a
signature. There are two competing perspectives on such
modifications. For most signers, mild modification of email is
immaterial to the authentication status of the email. For such
signers, a canonicalization algorithm that survives modest in-transit
modification is preferred.
Other signers demand that any modification of the email, however
minor, result in a signature verification failure. These signers
prefer a canonicalization algorithm that does not tolerate in-transit
modification of the signed email.
Some signers may be willing to accept modifications to header fields
that are within the bounds of email standards such as [RFC2822], but
are unwilling to accept any modification to the body of messages.
To satisfy all requirements, two canonicalization algorithms are
defined for each of the header and the body: a "simple" algorithm
that tolerates almost no modification and a "relaxed" algorithm that
tolerates common modifications such as whitespace replacement and
header field line rewrapping. A signer MAY specify either algorithm
for header or body when signing an email. If no canonicalization
algorithm is specified by the signer, the "simple" algorithm defaults
for both header and body. Verifiers MUST implement both
canonicalization algorithms. Note that the header and body may use
different canonicalization algorithms. Further canonicalization
algorithms MAY be defined in the future; verifiers MUST ignore any
signatures that use unrecognized canonicalization algorithms.
Canonicalization simply prepares the email for presentation to the
signing or verification algorithm. It MUST NOT change the
Allman, et al. Standards Track [Page 13]
RFC 4871 DKIM Signatures May 2007
transmitted data in any way. Canonicalization of header fields and
body are described below.
NOTE: This section assumes that the message is already in "network
normal" format (text is ASCII encoded, lines are separated with CRLF
characters, etc.). See also Section 5.3 for information about
normalizing the message.
3.4.1. The "simple" Header Canonicalization Algorithm
The "simple" header canonicalization algorithm does not change header
fields in any way. Header fields MUST be presented to the signing or
verification algorithm exactly as they are in the message being
signed or verified. In particular, header field names MUST NOT be
case folded and whitespace MUST NOT be changed.
3.4.2. The "relaxed" Header Canonicalization Algorithm
The "relaxed" header canonicalization algorithm MUST apply the
following steps in order:
o Convert all header field names (not the header field values) to
lowercase. For example, convert "SUBJect: AbC" to "subject: AbC".
o Unfold all header field continuation lines as described in
[RFC2822]; in particular, lines with terminators embedded in
continued header field values (that is, CRLF sequences followed by
WSP) MUST be interpreted without the CRLF. Implementations MUST
NOT remove the CRLF at the end of the header field value.
o Convert all sequences of one or more WSP characters to a single SP
character. WSP characters here include those before and after a
line folding boundary.
o Delete all WSP characters at the end of each unfolded header field
value.
o Delete any WSP characters remaining before and after the colon
separating the header field name from the header field value. The
colon separator MUST be retained.
3.4.3. The "simple" Body Canonicalization Algorithm
The "simple" body canonicalization algorithm ignores all empty lines
at the end of the message body. An empty line is a line of zero
length after removal of the line terminator. If there is no body or
no trailing CRLF on the message body, a CRLF is added. It makes no
Allman, et al. Standards Track [Page 14]
RFC 4871 DKIM Signatures May 2007
other changes to the message body. In more formal terms, the
"simple" body canonicalization algorithm converts "0*CRLF" at the end
of the body to a single "CRLF".
Note that a completely empty or missing body is canonicalized as a
single "CRLF"; that is, the canonicalized length will be 2 octets.
3.4.4. The "relaxed" Body Canonicalization Algorithm
The "relaxed" body canonicalization algorithm:
o Ignores all whitespace at the end of lines. Implementations MUST
NOT remove the CRLF at the end of the line.
o Reduces all sequences of WSP within a line to a single SP
character.
o Ignores all empty lines at the end of the message body. "Empty
line" is defined in Section 3.4.3.
INFORMATIVE NOTE: It should be noted that the relaxed body
canonicalization algorithm may enable certain types of extremely
crude "ASCII Art" attacks where a message may be conveyed by
adjusting the spacing between words. If this is a concern, the
"simple" body canonicalization algorithm should be used instead.
3.4.5. Body Length Limits
A body length count MAY be specified to limit the signature
calculation to an initial prefix of the body text, measured in
octets. If the body length count is not specified, the entire
message body is signed.
INFORMATIVE RATIONALE: This capability is provided because it is
very common for mailing lists to add trailers to messages (e.g.,
instructions how to get off the list). Until those messages are
also signed, the body length count is a useful tool for the
verifier since it may as a matter of policy accept messages having
valid signatures with extraneous data.
INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables
an attack in which an attacker modifies a message to include
content that solely benefits the attacker. It is possible for the
appended content to completely replace the original content in the
end recipient's eyes and to defeat duplicate message detection
algorithms. To avoid this attack, signers should be wary of using
Allman, et al. Standards Track [Page 15]
RFC 4871 DKIM Signatures May 2007
this tag, and verifiers might wish to ignore the tag or remove
text that appears after the specified content length, perhaps
based on other criteria.
The body length count allows the signer of a message to permit data
to be appended to the end of the body of a signed message. The body
length count MUST be calculated following the canonicalization
algorithm; for example, any whitespace ignored by a canonicalization
algorithm is not included as part of the body length count. Signers
of MIME messages that include a body length count SHOULD be sure that
the length extends to the closing MIME boundary string.
INFORMATIVE IMPLEMENTATION NOTE: A signer wishing to ensure that
the only acceptable modifications are to add to the MIME postlude
would use a body length count encompassing the entire final MIME
boundary string, including the final "--CRLF". A signer wishing
to allow additional MIME parts but not modification of existing
parts would use a body length count extending through the final
MIME boundary string, omitting the final "--CRLF". Note that this
only works for some MIME types, e.g., multipart/mixed but not
multipart/signed.
A body length count of zero means that the body is completely
unsigned.
Signers wishing to ensure that no modification of any sort can occur
should specify the "simple" canonicalization algorithm for both
header and body and omit the body length count.
3.4.6. Canonicalization Examples (INFORMATIVE)
In the following examples, actual whitespace is used only for
clarity. The actual input and output text is designated using
bracketed descriptors: "<SP>" for a space character, "<HTAB>" for a
tab character, and "<CRLF>" for a carriage-return/line-feed sequence.
For example, "X <SP> Y" and "X<SP>Y" represent the same three
characters.
Example 1: A message reading:
A: <SP> X <CRLF>
B <SP> : <SP> Y <HTAB><CRLF>
<HTAB> Z <SP><SP><CRLF>
<CRLF>
<SP> C <SP><CRLF>
D <SP><HTAB><SP> E <CRLF>
<CRLF>
<CRLF>
Allman, et al. Standards Track [Page 16]
RFC 4871 DKIM Signatures May 2007
when canonicalized using relaxed canonicalization for both header and
body results in a header reading:
a:X <CRLF>
b:Y <SP> Z <CRLF>
and a body reading:
<SP> C <CRLF>
D <SP> E <CRLF>
Example 2: The same message canonicalized using simple
canonicalization for both header and body results in a header
reading:
A: <SP> X <CRLF>
B <SP> : <SP> Y <HTAB><CRLF>
<HTAB> Z <SP><SP><CRLF>
and a body reading:
<SP> C <SP><CRLF>
D <SP><HTAB><SP> E <CRLF>
Example 3: When processed using relaxed header canonicalization and
simple body canonicalization, the canonicalized version has a header
of:
a:X <CRLF>
b:Y <SP> Z <CRLF>
and a body reading:
<SP> C <SP><CRLF>
D <SP><HTAB><SP> E <CRLF>
3.5. The DKIM-Signature Header Field
The signature of the email is stored in the DKIM-Signature header
field. This header field contains all of the signature and key-
fetching data. The DKIM-Signature value is a tag-list as described
in Section 3.2.
The DKIM-Signature header field SHOULD be treated as though it were a
trace header field as defined in Section 3.6 of [RFC2822], and hence
SHOULD NOT be reordered and SHOULD be prepended to the message.
Allman, et al. Standards Track [Page 17]
RFC 4871 DKIM Signatures May 2007
The DKIM-Signature header field being created or verified is always
included in the signature calculation, after the rest of the header
fields being signed; however, when calculating or verifying the
signature, the value of the "b=" tag (signature value) of that DKIM-
Signature header field MUST be treated as though it were an empty
string. Unknown tags in the DKIM-Signature header field MUST be
included in the signature calculation but MUST be otherwise ignored
by verifiers. Other DKIM-Signature header fields that are included
in the signature should be treated as normal header fields; in
particular, the "b=" tag is not treated specially.
The encodings for each field type are listed below. Tags described
as qp-section are encoded as described in Section 6.7 of MIME Part
One [RFC2045], with the additional conversion of semicolon characters
to "=3B"; intuitively, this is one line of quoted-printable encoded
text. The dkim-quoted-printable syntax is defined in Section 2.6.
Tags on the DKIM-Signature header field along with their type and
requirement status are shown below. Unrecognized tags MUST be
ignored.
v= Version (MUST be included). This tag defines the version of this
specification that applies to the signature record. It MUST have
the value "1". Note that verifiers must do a string comparison
on this value; for example, "1" is not the same as "1.0".
ABNF:
sig-v-tag = %x76 [FWS] "=" [FWS] "1"
INFORMATIVE NOTE: DKIM-Signature version numbers are expected
to increase arithmetically as new versions of this
specification are released.
a= The algorithm used to generate the signature (plain-text;
REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256";
signers SHOULD sign using "rsa-sha256". See Section 3.3 for a
description of algorithms.
ABNF:
sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg
sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h
sig-a-tag-k = "rsa" / x-sig-a-tag-k
sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h
x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) ; for later extension
x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) ; for later extension
Allman, et al. Standards Track [Page 18]
RFC 4871 DKIM Signatures May 2007
b= The signature data (base64; REQUIRED). Whitespace is ignored in
this value and MUST be ignored when reassembling the original
signature. In particular, the signing process can safely insert
FWS in this value in arbitrary places to conform to line-length
limits. See Signer Actions (Section 5) for how the signature is
computed.
ABNF:
sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data
sig-b-tag-data = base64string
bh= The hash of the canonicalized body part of the message as limited
by the "l=" tag (base64; REQUIRED). Whitespace is ignored in
this value and MUST be ignored when reassembling the original
signature. In particular, the signing process can safely insert
FWS in this value in arbitrary places to conform to line-length
limits. See Section 3.7 for how the body hash is computed.
ABNF:
sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data
sig-bh-tag-data = base64string
c= Message canonicalization (plain-text; OPTIONAL, default is
"simple/simple"). This tag informs the verifier of the type of
canonicalization used to prepare the message for signing. It
consists of two names separated by a "slash" (%d47) character,
corresponding to the header and body canonicalization algorithms
respectively. These algorithms are described in Section 3.4. If
only one algorithm is named, that algorithm is used for the
header and "simple" is used for the body. For example,
"c=relaxed" is treated the same as "c=relaxed/simple".
ABNF:
sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg
["/" sig-c-tag-alg]
sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg
x-sig-c-tag-alg = hyphenated-word ; for later extension
d= The domain of the signing entity (plain-text; REQUIRED). This is
the domain that will be queried for the public key. This domain
MUST be the same as or a parent domain of the "i=" tag (the
signing identity, as described below), or it MUST meet the
requirements for parent domain signing described in Section 3.8.
When presented with a signature that does not meet these
requirement, verifiers MUST consider the signature invalid.
Allman, et al. Standards Track [Page 19]
RFC 4871 DKIM Signatures May 2007
Internationalized domain names MUST be encoded as described in
[RFC3490].
ABNF:
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain)
; from RFC 2821 Domain, but excluding address-literal
h= Signed header fields (plain-text, but see description; REQUIRED).
A colon-separated list of header field names that identify the
header fields presented to the signing algorithm. The field MUST
contain the complete list of header fields in the order presented
to the signing algorithm. The field MAY contain names of header
fields that do not exist when signed; nonexistent header fields
do not contribute to the signature computation (that is, they are
treated as the null input, including the header field name, the
separating colon, the header field value, and any CRLF
terminator). The field MUST NOT include the DKIM-Signature
header field that is being created or verified, but may include
others. Folding whitespace (FWS) MAY be included on either side
of the colon separator. Header field names MUST be compared
against actual header field names in a case-insensitive manner.
This list MUST NOT be empty. See Section 5.4 for a discussion of
choosing header fields to sign.
ABNF:
sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name
0*( *FWS ":" *FWS hdr-name )
hdr-name = field-name
INFORMATIVE EXPLANATION: By "signing" header fields that do not
actually exist, a signer can prevent insertion of those
header fields before verification. However, since a signer
cannot possibly know what header fields might be created in
the future, and that some MUAs might present header fields
that are embedded inside a message (e.g., as a message/rfc822
content type), the security of this solution is not total.
INFORMATIVE EXPLANATION: The exclusion of the header field name
and colon as well as the header field value for non-existent
header fields prevents an attacker from inserting an actual
header field with a null value.
Allman, et al. Standards Track [Page 20]
RFC 4871 DKIM Signatures May 2007
i= Identity of the user or agent (e.g., a mailing list manager) on
behalf of which this message is signed (dkim-quoted-printable;
OPTIONAL, default is an empty Local-part followed by an "@"
followed by the domain from the "d=" tag). The syntax is a
standard email address where the Local-part MAY be omitted. The
domain part of the address MUST be the same as or a subdomain of
the value of the "d=" tag.
Internationalized domain names MUST be converted using the steps
listed in Section 4 of [RFC3490] using the "ToASCII" function.
ABNF:
sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" domain-name
INFORMATIVE NOTE: The Local-part of the "i=" tag is optional
because in some cases a signer may not be able to establish a
verified individual identity. In such cases, the signer may
wish to assert that although it is willing to go as far as
signing for the domain, it is unable or unwilling to commit
to an individual user name within their domain. It can do so
by including the domain part but not the Local-part of the
identity.
INFORMATIVE DISCUSSION: This document does not require the value
of the "i=" tag to match the identity in any message header
fields. This is considered to be a verifier policy issue.
Constraints between the value of the "i=" tag and other
identities in other header fields seek to apply basic
authentication into the semantics of trust associated with a
role such as content author. Trust is a broad and complex
topic and trust mechanisms are subject to highly creative
attacks. The real-world efficacy of any but the most basic
bindings between the "i=" value and other identities is not
well established, nor is its vulnerability to subversion by
an attacker. Hence reliance on the use of these options
should be strictly limited. In particular, it is not at all
clear to what extent a typical end-user recipient can rely on
any assurances that might be made by successful use of the
"i=" options.
l= Body length count (plain-text unsigned decimal integer; OPTIONAL,
default is entire body). This tag informs the verifier of the
number of octets in the body of the email after canonicalization
included in the cryptographic hash, starting from 0 immediately
following the CRLF preceding the body. This value MUST NOT be
larger than the actual number of octets in the canonicalized
message body.
Allman, et al. Standards Track [Page 21]
RFC 4871 DKIM Signatures May 2007
INFORMATIVE IMPLEMENTATION WARNING: Use of the "l=" tag might
allow display of fraudulent content without appropriate
warning to end users. The "l=" tag is intended for
increasing signature robustness when sending to mailing lists
that both modify their content and do not sign their
messages. However, using the "l=" tag enables attacks in
which an intermediary with malicious intent modifies a
message to include content that solely benefits the attacker.
It is possible for the appended content to completely replace
the original content in the end recipient's eyes and to
defeat duplicate message detection algorithms. Examples are
described in Security Considerations (Section 8). To avoid
this attack, signers should be extremely wary of using this
tag, and verifiers might wish to ignore the tag or remove
text that appears after the specified content length.
INFORMATIVE NOTE: The value of the "l=" tag is constrained to 76
decimal digits. This constraint is not intended to predict
the size of future messages or to require implementations to
use an integer representation large enough to represent the
maximum possible value, but is intended to remind the
implementer to check the length of this and all other tags
during verification and to test for integer overflow when
decoding the value. Implementers may need to limit the
actual value expressed to a value smaller than 10^76, e.g.,
to allow a message to fit within the available storage space.
ABNF:
sig-l-tag = %x6c [FWS] "=" [FWS] 1*76DIGIT
q= A colon-separated list of query methods used to retrieve the
public key (plain-text; OPTIONAL, default is "dns/txt"). Each
query method is of the form "type[/options]", where the syntax
and semantics of the options depend on the type and specified
options. If there are multiple query mechanisms listed, the
choice of query mechanism MUST NOT change the interpretation of
the signature. Implementations MUST use the recognized query
mechanisms in the order presented.
Currently, the only valid value is "dns/txt", which defines the DNS
TXT record lookup algorithm described elsewhere in this document.
The only option defined for the "dns" query type is "txt", which
MUST be included. Verifiers and signers MUST support "dns/txt".
Allman, et al. Standards Track [Page 22]
RFC 4871 DKIM Signatures May 2007
ABNF:
sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method
*([FWS] ":" [FWS] sig-q-tag-method)
sig-q-tag-method = "dns/txt" / x-sig-q-tag-type
["/" x-sig-q-tag-args]
x-sig-q-tag-type = hyphenated-word ; for future extension
x-sig-q-tag-args = qp-hdr-value
s= The selector subdividing the namespace for the "d=" (domain) tag
(plain-text; REQUIRED).
ABNF:
sig-s-tag = %x73 [FWS] "=" [FWS] selector
t= Signature Timestamp (plain-text unsigned decimal integer;
RECOMMENDED, default is an unknown creation time). The time that
this signature was created. The format is the number of seconds
since 00:00:00 on January 1, 1970 in the UTC time zone. The
value is expressed as an unsigned integer in decimal ASCII. This
value is not constrained to fit into a 31- or 32-bit integer.
Implementations SHOULD be prepared to handle values up to at
least 10^12 (until approximately AD 200,000; this fits into 40
bits). To avoid denial-of-service attacks, implementations MAY
consider any value longer than 12 digits to be infinite. Leap
seconds are not counted. Implementations MAY ignore signatures
that have a timestamp in the future.
ABNF:
sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT
x= Signature Expiration (plain-text unsigned decimal integer;
RECOMMENDED, default is no expiration). The format is the same
as in the "t=" tag, represented as an absolute date, not as a
time delta from the signing timestamp. The value is expressed as
an unsigned integer in decimal ASCII, with the same constraints
on the value in the "t=" tag. Signatures MAY be considered
invalid if the verification time at the verifier is past the
expiration date. The verification time should be the time that
the message was first received at the administrative domain of
the verifier if that time is reliably available; otherwise the
current time should be used. The value of the "x=" tag MUST be
greater than the value of the "t=" tag if both are present.
Allman, et al. Standards Track [Page 23]
RFC 4871 DKIM Signatures May 2007
INFORMATIVE NOTE: The "x=" tag is not intended as an anti-replay
defense.
ABNF:
sig-x-tag = %x78 [FWS] "=" [FWS] 1*12DIGIT
z= Copied header fields (dkim-quoted-printable, but see description;
OPTIONAL, default is null). A vertical-bar-separated list of
selected header fields present when the message was signed,
including both the field name and value. It is not required to
include all header fields present at the time of signing. This
field need not contain the same header fields listed in the "h="
tag. The header field text itself must encode the vertical bar
("|", %x7C) character (i.e., vertical bars in the "z=" text are
metacharacters, and any actual vertical bar characters in a
copied header field must be encoded). Note that all whitespace
must be encoded, including whitespace between the colon and the
header field value. After encoding, FWS MAY be added at
arbitrary locations in order to avoid excessively long lines;
such whitespace is NOT part of the value of the header field, and
MUST be removed before decoding.
The header fields referenced by the "h=" tag refer to the fields in
the RFC 2822 header of the message, not to any copied fields in
the "z=" tag. Copied header field values are for diagnostic use.
Header fields with characters requiring conversion (perhaps from
legacy MTAs that are not [RFC2822] compliant) SHOULD be converted
as described in MIME Part Three [RFC2047].
ABNF:
sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy
*( [FWS] "|" sig-z-tag-copy )
sig-z-tag-copy = hdr-name ":" qp-hdr-value
qp-hdr-value = dkim-quoted-printable ; with "|" encoded
INFORMATIVE EXAMPLE of a signature header field spread across
multiple continuation lines:
Allman, et al. Standards Track [Page 24]
RFC 4871 DKIM Signatures May 2007
DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane;
c=simple; q=dns/txt; i=@eng.example.net;
t=1117574938; x=1118006938;
h=from:to:subject:date;
z=From:foo@eng.example.net|To:joe@example.com|
Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR
3.6. Key Management and Representation
Signature applications require some level of assurance that the
verification public key is associated with the claimed signer. Many
applications achieve this by using public key certificates issued by
a trusted third party. However, DKIM can achieve a sufficient level
of security, with significantly enhanced scalability, by simply
having the verifier query the purported signer's DNS entry (or some
security-equivalent) in order to retrieve the public key.
DKIM keys can potentially be stored in multiple types of key servers
and in multiple formats. The storage and format of keys are
irrelevant to the remainder of the DKIM algorithm.
Parameters to the key lookup algorithm are the type of the lookup
(the "q=" tag), the domain of the signer (the "d=" tag of the DKIM-
Signature header field), and the selector (the "s=" tag).
public_key = dkim_find_key(q_val, d_val, s_val)
This document defines a single binding, using DNS TXT records to
distribute the keys. Other bindings may be defined in the future.
3.6.1. Textual Representation
It is expected that many key servers will choose to present the keys
in an otherwise unstructured text format (for example, an XML form
would not be considered to be unstructured text for this purpose).
The following definition MUST be used for any DKIM key represented in
an otherwise unstructured textual form.
The overall syntax is a tag-list as described in Section 3.2. The
current valid tags are described below. Other tags MAY be present
and MUST be ignored by any implementation that does not understand
them.
Allman, et al. Standards Track [Page 25]
RFC 4871 DKIM Signatures May 2007
v= Version of the DKIM key record (plain-text; RECOMMENDED, default
is "DKIM1"). If specified, this tag MUST be set to "DKIM1"
(without the quotes). This tag MUST be the first tag in the
record. Records beginning with a "v=" tag with any other value
MUST be discarded. Note that verifiers must do a string
comparison on this value; for example, "DKIM1" is not the same as
"DKIM1.0".
ABNF:
key-v-tag = %x76 [FWS] "=" [FWS] "DKIM1"
g= Granularity of the key (plain-text; OPTIONAL, default is "*").
This value MUST match the Local-part of the "i=" tag of the DKIM-
Signature header field (or its default value of the empty string
if "i=" is not specified), with a single, optional "*" character
matching a sequence of zero or more arbitrary characters
("wildcarding"). An email with a signing address that does not
match the value of this tag constitutes a failed verification.
The intent of this tag is to constrain which signing address can
legitimately use this selector, for example, when delegating a
key to a third party that should only be used for special
purposes. Wildcarding allows matching for addresses such as
"user+*" or "*-offer". An empty "g=" value never matches any
addresses.
ABNF:
key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart
key-g-tag-lpart = [dot-atom-text] ["*" [dot-atom-text] ]
h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
allowing all algorithms). A colon-separated list of hash
algorithms that might be used. Signers and Verifiers MUST
support the "sha256" hash algorithm. Verifiers MUST also support
the "sha1" hash algorithm.
ABNF:
key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg
0*( [FWS] ":" [FWS] key-h-tag-alg )
key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg
x-key-h-tag-alg = hyphenated-word ; for future extension
Allman, et al. Standards Track [Page 26]
RFC 4871 DKIM Signatures May 2007
k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and
verifiers MUST support the "rsa" key type. The "rsa" key type
indicates that an ASN.1 DER-encoded [ITU.X660.1997] RSAPublicKey
[RFC3447] (see Sections 3.1 and A.1.1) is being used in the "p="
tag. (Note: the "p=" tag further encodes the value using the
base64 algorithm.)
ABNF:
key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type
key-k-tag-type = "rsa" / x-key-k-tag-type
x-key-k-tag-type = hyphenated-word ; for future extension
n= Notes that might be of interest to a human (qp-section; OPTIONAL,
default is empty). No interpretation is made by any program.
This tag should be used sparingly in any key server mechanism
that has space limitations (notably DNS). This is intended for
use by administrators, not end users.
ABNF:
key-n-tag = %x6e [FWS] "=" [FWS] qp-section
p= Public-key data (base64; REQUIRED). An empty value means that
this public key has been revoked. The syntax and semantics of
this tag value before being encoded in base64 are defined by the
"k=" tag.
INFORMATIVE RATIONALE: If a private key has been compromised
or otherwise disabled (e.g., an outsourcing contract has been
terminated), a signer might want to explicitly state that it
knows about the selector, but all messages using that
selector should fail verification. Verifiers should ignore
any DKIM-Signature header fields with a selector referencing
a revoked key.
ABNF:
key-p-tag = %x70 [FWS] "=" [ [FWS] base64string ]
INFORMATIVE NOTE: A base64string is permitted to include white
space (FWS) at arbitrary places; however, any CRLFs must be
followed by at least one WSP character. Implementors and
administrators are cautioned to ensure that selector TXT
records conform to this specification.
Allman, et al. Standards Track [Page 27]
RFC 4871 DKIM Signatures May 2007
s= Service Type (plain-text; OPTIONAL; default is "*"). A colon-
separated list of service types to which this record applies.
Verifiers for a given service type MUST ignore this record if the
appropriate type is not listed. Currently defined service types
are as follows:
* matches all service types
email electronic mail (not necessarily limited to SMTP)
This tag is intended to constrain the use of keys for other
purposes, should use of DKIM be defined by other services in the
future.
ABNF:
key-s-tag = %x73 [FWS] "=" [FWS] key-s-tag-type
0*( [FWS] ":" [FWS] key-s-tag-type )
key-s-tag-type = "email" / "*" / x-key-s-tag-type
x-key-s-tag-type = hyphenated-word ; for future extension
t= Flags, represented as a colon-separated list of names (plain-
text; OPTIONAL, default is no flags set). The defined flags are
as follows:
y This domain is testing DKIM. Verifiers MUST NOT treat
messages from signers in testing mode differently from
unsigned email, even should the signature fail to verify.
Verifiers MAY wish to track testing mode results to assist
the signer.
s Any DKIM-Signature header fields using the "i=" tag MUST have
the same domain value on the right-hand side of the "@" in
the "i=" tag and the value of the "d=" tag. That is, the
"i=" domain MUST NOT be a subdomain of