tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6376

 Errata 
STD 76
Pages: 76
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: DKIM

DomainKeys Identified Mail (DKIM) Signatures

Part 1 of 4, p. 1 to 10
None       Next RFC Part

Obsoletes:    4871    5672


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                   D. Crocker, Ed.
Request for Comments: 6376                   Brandenburg InternetWorking
Obsoletes: 4871, 5672                                     T. Hansen, Ed.
Category: Standards Track                              AT&T Laboratories
ISSN: 2070-1721                                        M. Kucherawy, Ed.
                                                               Cloudmark
                                                          September 2011


              DomainKeys Identified Mail (DKIM) Signatures

Abstract

   DomainKeys Identified Mail (DKIM) permits a person, role, or
   organization that owns the signing domain to claim some
   responsibility for a message by associating the domain with the
   message.  This can be an author's organization, an operational relay,
   or one of their agents.  DKIM separates the question of the identity
   of the Signer of the message from the purported author of the
   message.  Assertion of responsibility is validated through a
   cryptographic signature and by querying the Signer's domain directly
   to retrieve the appropriate public key.  Message transit from author
   to recipient is through relays that typically make no substantive
   change to the message content and thus preserve the DKIM signature.

   This memo obsoletes RFC 4871 and RFC 5672.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6376.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Page 2 
   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  DKIM Architecture Documents  . . . . . . . . . . . . . . .  5
     1.2.  Signing Identity . . . . . . . . . . . . . . . . . . . . .  5
     1.3.  Scalability  . . . . . . . . . . . . . . . . . . . . . . .  5
     1.4.  Simple Key Management  . . . . . . . . . . . . . . . . . .  6
     1.5.  Data Integrity . . . . . . . . . . . . . . . . . . . . . .  6
   2.  Terminology and Definitions  . . . . . . . . . . . . . . . . .  6
     2.1.  Signers  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Verifiers  . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.3.  Identity . . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.4.  Identifier . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.5.  Signing Domain Identifier (SDID) . . . . . . . . . . . . .  7
     2.6.  Agent or User Identifier (AUID)  . . . . . . . . . . . . .  7
     2.7.  Identity Assessor  . . . . . . . . . . . . . . . . . . . .  7
     2.8.  Whitespace . . . . . . . . . . . . . . . . . . . . . . . .  8
     2.9.  Imported ABNF Tokens . . . . . . . . . . . . . . . . . . .  8
     2.10. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . .  9
     2.11. DKIM-Quoted-Printable  . . . . . . . . . . . . . . . . . .  9
   3.  Protocol Elements  . . . . . . . . . . . . . . . . . . . . . . 10
     3.1.  Selectors  . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.2.  Tag=Value Lists  . . . . . . . . . . . . . . . . . . . . . 12
     3.3.  Signing and Verification Algorithms  . . . . . . . . . . . 13
     3.4.  Canonicalization . . . . . . . . . . . . . . . . . . . . . 14
     3.5.  The DKIM-Signature Header Field  . . . . . . . . . . . . . 18

Top      ToC       Page 3 
     3.6.  Key Management and Representation  . . . . . . . . . . . . 26
     3.7.  Computing the Message Hashes . . . . . . . . . . . . . . . 29
     3.8.  Input Requirements . . . . . . . . . . . . . . . . . . . . 32
     3.9.  Output Requirements  . . . . . . . . . . . . . . . . . . . 32
     3.10. Signing by Parent Domains  . . . . . . . . . . . . . . . . 33
     3.11. Relationship between SDID and AUID . . . . . . . . . . . . 33
   4.  Semantics of Multiple Signatures . . . . . . . . . . . . . . . 34
     4.1.  Example Scenarios  . . . . . . . . . . . . . . . . . . . . 34
     4.2.  Interpretation . . . . . . . . . . . . . . . . . . . . . . 35
   5.  Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 36
     5.1.  Determine Whether the Email Should Be Signed and by
           Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
     5.2.  Select a Private Key and Corresponding Selector
           Information  . . . . . . . . . . . . . . . . . . . . . . . 37
     5.3.  Normalize the Message to Prevent Transport Conversions . . 37
     5.4.  Determine the Header Fields to Sign  . . . . . . . . . . . 38
     5.5.  Compute the Message Hash and Signature . . . . . . . . . . 43
     5.6.  Insert the DKIM-Signature Header Field . . . . . . . . . . 43
   6.  Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 43
     6.1.  Extract Signatures from the Message  . . . . . . . . . . . 44
     6.2.  Communicate Verification Results . . . . . . . . . . . . . 49
     6.3.  Interpret Results/Apply Local Policy . . . . . . . . . . . 50
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 51
     7.1.  Email Authentication Methods Registry  . . . . . . . . . . 51
     7.2.  DKIM-Signature Tag Specifications  . . . . . . . . . . . . 51
     7.3.  DKIM-Signature Query Method Registry . . . . . . . . . . . 52
     7.4.  DKIM-Signature Canonicalization Registry . . . . . . . . . 52
     7.5.  _domainkey DNS TXT Resource Record Tag Specifications  . . 53
     7.6.  DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 53
     7.7.  DKIM Hash Algorithms Registry  . . . . . . . . . . . . . . 54
     7.8.  DKIM Service Types Registry  . . . . . . . . . . . . . . . 54
     7.9.  DKIM Selector Flags Registry . . . . . . . . . . . . . . . 55
     7.10. DKIM-Signature Header Field  . . . . . . . . . . . . . . . 55
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 55
     8.1.  ASCII Art Attacks  . . . . . . . . . . . . . . . . . . . . 55
     8.2.  Misuse of Body Length Limits ("l=" Tag)  . . . . . . . . . 55
     8.3.  Misappropriated Private Key  . . . . . . . . . . . . . . . 56
     8.4.  Key Server Denial-of-Service Attacks . . . . . . . . . . . 56
     8.5.  Attacks against the DNS  . . . . . . . . . . . . . . . . . 57
     8.6.  Replay/Spam Attacks  . . . . . . . . . . . . . . . . . . . 57
     8.7.  Limits on Revoking Keys  . . . . . . . . . . . . . . . . . 58
     8.8.  Intentionally Malformed Key Records  . . . . . . . . . . . 58
     8.9.  Intentionally Malformed DKIM-Signature Header Fields . . . 58
     8.10. Information Leakage  . . . . . . . . . . . . . . . . . . . 58
     8.11. Remote Timing Attacks  . . . . . . . . . . . . . . . . . . 59
     8.12. Reordered Header Fields  . . . . . . . . . . . . . . . . . 59
     8.13. RSA Attacks  . . . . . . . . . . . . . . . . . . . . . . . 59
     8.14. Inappropriate Signing by Parent Domains  . . . . . . . . . 59

Top      ToC       Page 4 
     8.15. Attacks Involving Extra Header Fields  . . . . . . . . . . 60
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 61
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 61
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 62
   Appendix A.  Example of Use (INFORMATIVE)  . . . . . . . . . . . . 64
     A.1.  The User Composes an Email . . . . . . . . . . . . . . . . 64
     A.2.  The Email is Signed  . . . . . . . . . . . . . . . . . . . 65
     A.3.  The Email Signature is Verified  . . . . . . . . . . . . . 66
   Appendix B.  Usage Examples (INFORMATIVE)  . . . . . . . . . . . . 67
     B.1.  Alternate Submission Scenarios . . . . . . . . . . . . . . 67
     B.2.  Alternate Delivery Scenarios . . . . . . . . . . . . . . . 69
   Appendix C.  Creating a Public Key (INFORMATIVE) . . . . . . . . . 71
     C.1.  Compatibility with DomainKeys Key Records  . . . . . . . . 72
     C.2.  RFC 4871 Compatibility . . . . . . . . . . . . . . . . . . 73
   Appendix D.  MUA Considerations (INFORMATIVE)  . . . . . . . . . . 73
   Appendix E.  Changes since RFC 4871  . . . . . . . . . . . . . . . 73
   Appendix F.  Acknowledgments . . . . . . . . . . . . . . . . . . . 75

1.  Introduction

   DomainKeys Identified Mail (DKIM) permits a person, role, or
   organization to claim some responsibility for a message by
   associating a domain name [RFC1034] with the message [RFC5322], which
   they are authorized to use.  This can be an author's organization, an
   operational relay, or one of their agents.  Assertion of
   responsibility is validated through a cryptographic signature and by
   querying the Signer's domain directly to retrieve the appropriate
   public key.  Message transit from author to recipient is through
   relays that typically make no substantive change to the message
   content and thus preserve the DKIM signature.  A message can contain
   multiple signatures, from the same or different organizations
   involved with the message.

   The approach taken by DKIM differs from previous approaches to
   message signing (e.g., Secure/Multipurpose Internet Mail Extensions
   (S/MIME) [RFC5751], OpenPGP [RFC4880]) 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;

Top      ToC       Page 5 
   o  signature verification failure does not force rejection of the
      message;

   o  no attempt is made to include encryption as part of the mechanism;
      and

   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; and

   o  allows delegation of signing to third parties.

1.1.  DKIM Architecture Documents

   Readers are advised to be familiar with the material in [RFC4686],
   [RFC5585], and [RFC5863], which provide the background for the
   development of DKIM, an overview of the service, and deployment and
   operations guidance and advice, respectively.

1.2.  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.3.  Scalability

   DKIM is designed to support the extreme scalability requirements that
   characterize the email identification problem.  There are many
   millions of domains and a much larger number of individual addresses.

Top      ToC       Page 6 
   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.4.  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.

1.5.  Data Integrity

   A DKIM signature associates the "d=" name with the computed hash of
   some or all of the message (see Section 3.7) in order to prevent the
   reuse of the signature with different messages.  Verifying the
   signature asserts that the hashed content has not changed since it
   was signed and asserts nothing else about "protecting" the end-to-end
   integrity of the message.

2.  Terminology and Definitions

   This section defines terms used in the rest of the document.

   DKIM is designed to operate within the Internet Mail service, as
   defined in [RFC5598].  Basic email terminology is taken from that
   specification.

   Syntax descriptions use Augmented BNF (ABNF) [RFC5234].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].  These words take their normative meanings only when they
   are presented in ALL UPPERCASE.

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

Top      ToC       Page 7 
   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.  Identity

   A person, role, or organization.  In the context of DKIM, examples
   include the author, the author's organization, an ISP along the
   handling path, an independent trust assessment service, and a mailing
   list operator.

2.4.  Identifier

   A label that refers to an identity.

2.5.  Signing Domain Identifier (SDID)

   A single domain name that is the mandatory payload output of DKIM and
   that refers to the identity claiming some responsibility for the
   message by signing it.  It is specified in Section 3.5.

2.6.  Agent or User Identifier (AUID)

   A single identifier that refers to the agent or user on behalf of
   whom the Signing Domain Identifier (SDID) has taken responsibility.
   The AUID comprises a domain name and an optional <local-part>.  The
   domain name is the same as that used for the SDID or is a subdomain
   of it.  For DKIM processing, the domain name portion of the AUID has
   only basic domain name semantics; any possible owner-specific
   semantics are outside the scope of DKIM.  It is specified in
   Section 3.5.

   Note that acceptable values for the AUID may be constrained via a
   flag in the public-key record.  (See Section 3.6.1.)

2.7.  Identity Assessor

   An element in the mail system that consumes DKIM's payload, which is
   the responsible Signing Domain Identifier (SDID).  The Identity
   Assessor is dedicated to the assessment of the delivered identifier.

Top      ToC       Page 8 
   Other DKIM (and non-DKIM) values can also be used by the Identity
   Assessor (if they are available) to provide a more general message
   evaluation filtering engine.  However, this additional activity is
   outside the scope of this specification.

2.8.  Whitespace

   There are three forms of whitespace:

   o  WSP represents simple whitespace, i.e., a space or a tab character
      (formal definition in [RFC5234]).

   o  LWSP is linear whitespace, defined as WSP plus CRLF (formal
      definition in [RFC5234]).

   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 [RFC5322] except for
   the exclusion of obs-FWS.

2.9.  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 [RFC5321]:

   o  "local-part" (implementation warning: this permits quoted strings)

   o  "sub-domain"

   The following tokens are imported from [RFC5322]:

   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)

Top      ToC       Page 9 
   o  "hex-octet" (a quoted-printable encoded octet)

      INFORMATIVE NOTE: Be aware that the ABNF in [RFC2045] does not
      obey the rules of [RFC5234] and must be interpreted accordingly,
      particularly as regards case folding.

   Other tokens not defined herein are imported from [RFC5234].  These
   are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF,
   etc.

2.10.  Common ABNF Tokens

   The following ABNF tokens are used elsewhere in this document:

   hyphenated-word =  ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ]
   ALPHADIGITPS    =  (ALPHA / DIGIT / "+" / "/")
   base64string    =  ALPHADIGITPS *([FWS] ALPHADIGITPS)
                      [ [FWS] "=" [ [FWS] "=" ] ]
   hdr-name        =  field-name
   qp-hdr-value    =  dkim-quoted-printable    ; with "|" encoded

2.11.  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.  Use of characters not listed as "mail-safe"
   in [RFC2049] is NOT RECOMMENDED.

   ABNF:

   dkim-quoted-printable =  *(FWS / hex-octet / dkim-safe-char)
                               ; hex-octet is from RFC2045
   dkim-safe-char        =  %x21-3A / %x3C / %x3E-7E
                               ; '!' - ':', '<', '>' - '~'

Top      ToC       Page 10 
      INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted-
      Printable as defined in [RFC2045] in several important ways:

      1.  Whitespace in the input text, including CR and LF, must be
          encoded.  [RFC2045] 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, [RFC2045] 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 10 continued on part 2)

Next RFC Part