Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4871

DomainKeys Identified Mail (DKIM) Signatures

Pages: 71
Obsoletes:  4870
Obsoleted by:  6376
Updated by:  5672
Part 1 of 4 – Pages 1 to 8
None   None   Next

ToP   noToC   RFC4871 - Page 1
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".
ToP   noToC   RFC4871 - Page 2

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
ToP   noToC   RFC4871 - Page 3
     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
ToP   noToC   RFC4871 - Page 4

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.
ToP   noToC   RFC4871 - Page 5

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].
ToP   noToC   RFC4871 - Page 6

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] ] ]
ToP   noToC   RFC4871 - Page 7

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.
ToP   noToC   RFC4871 - Page 8
   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).



(page 8 continued on part 2)

Next Section