DomainKeys Identified Mail                                     T. Hansen
Internet-Draft                                         AT&T Laboratories
Intended status: Informational                                D. Crocker
Expires: December 13, 2007 May 14, 2008                        Brandenburg InternetWorking
                                                         P. Hallam-Baker
                                                           VeriSign Inc.
                                                           June
                                                       November 11, 2007

           DomainKeys Identified Mail (DKIM) Service Overview
                      draft-ietf-dkim-overview-05
                      draft-ietf-dkim-overview-06

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 13, 2007. May 14, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   DomainKeys Identified Mail (DKIM) associates a "responsible" identity
   with allows an organization to take
   responsibility for a message and provides message, in a means of verifying way that can be validated by a
   recipient.  The organization can be the association
   is legitimate.  [RFC4871] author's, the originating
   sending site, an intermediary, or one of their agent's.  DKIM defines
   a domain-level digital signature authentication framework for email email,
   using public-key cryptography and key server technology.  This
   permits verifying the source or intermediary for signer of a message, as well as the contents integrity
   of messages. its contents.  The ultimate goal of this framework is to permit a
   signing domain to assert responsibility for a message, thus proving
   and protecting the identity associated with the message and the
   integrity of the messages itself, while retaining the functionality
   of Internet email as it is known today.  Such protection of email
   identity may can assist in the global control of "spam" and "phishing".
   This document provides an overview of DKIM, the DKIM service and describes
   how it can fit into a messaging service, service.  It also describes how it DKIM
   relates to other IETF message signature technologies, and includes
   implementation and migration considerations. technologies.

Table of Contents

   1.  DKIM Framework  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Introduction  Prior Work . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Goals  Discussion Venue . . . . . . . . . . . . . . . . . . . . .  5
   2.  Internet Mail Background . . . . . . . . . . . . .  9
     1.3.  Function . . . . . .  5
     2.1.  Administrative Management Domain (ADMD)  . . . . . . . . .  6
     2.2.  DKIM Placement within an ADMD  . . . . . . . . . . . . 11
     1.4.  Service Architecture . .  8
   3.  The DKIM Value Proposition . . . . . . . . . . . . . . . . . 13
   2.  Deployment and Operation .  8
   4.  The Role of Trust  . . . . . . . . . . . . . . . . . . . . . . 10
   5.  DKIM Base Goals . . . . . . . . . . . . 15
     2.1.  Development . . . . . . . . . . . . . . 10
     5.1.  Functional Goals . . . . . . . . . 15
     2.2.  Email Infrastructure Agents . . . . . . . . . . . . 10
     5.2.  Operational Goals  . . . . 16
     2.3.  Filtering . . . . . . . . . . . . . . . . 11
   6.  DKIM Function  . . . . . . . . 17
     2.4.  DNS Server . . . . . . . . . . . . . . . . 13
     6.1.  The Basic Signing Service  . . . . . . . . 18
     2.5.  Deployment . . . . . . . . 13
     6.2.  Characteristics of a DKIM signature  . . . . . . . . . . . 13
     6.3.  The Selector construct . . . . . 18
     2.6.  On-going Operations . . . . . . . . . . . . . 13
     6.4.  Verification . . . . . . 24
     2.7.  Example Uses . . . . . . . . . . . . . . . . . 14
   7.  Service Architecture . . . . . . 27
   3.  Acknowledgements . . . . . . . . . . . . . . . 14
     7.1.  Administration and Maintenance . . . . . . . . 29
   4.  Informative References . . . . . . 16
     7.2.  Signing  . . . . . . . . . . . . . . 29
   Authors' Addresses . . . . . . . . . . . 17
     7.3.  Verifying  . . . . . . . . . . . . . 30
   Intellectual Property and Copyright Statements . . . . . . . . . . 32

1.  DKIM Framework

1.1.  Introduction

   DomainKeys Identified Mail (DKIM) associates a "responsible" identity
   with a message and provides a means of verifying that the association
   is legitimate.  [RFC4871] DKIM accomplishes this by defining a
   domain-level authentication framework for email using public-key
   cryptography and key server technology.  This permits verifying the
   source . 17
     7.4.  Unverified or intermediary Unsigned Mail  . . . . . . . . . . . . . . . 17
     7.5.  Evaluating . . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   11. Informative References . . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20

1.  Introduction

   DomainKeys Identified Mail (DKIM) allows an organization to take
   responsibility for a message, in a way that can be validated by a
   recipient.  The organization can be the author's, the originating
   sending site, an intermediary, or one of their agent's.  DKIM defines
   a domain-level digital signature authentication framework for email,
   using public-key cryptography and key server technology.  This
   permits verifying the signer of a message, as well as the contents integrity
   of
   messages. its contents.  DKIM will also provide accomplishes this by defining a mechanism that permits potential domain-level
   authentication framework for email signers to using public-key cryptography and
   key server technology [RFC4871].  This permits verifying a message
   source, an intermediary, or one of their agents, as well as the
   integrity of its contents.  DKIM will also provide a mechanism that
   permits potential email signers to publish information about their
   email signing practices; this will permit email receivers to make
   additional assessments of unsigned messages.

   The ultimate goal of this framework is to permit a domain to assert
   responsibility for a message, thus proving and protecting the
   identity associated with the message and the integrity of the
   messages itself, while retaining the functionality of Internet email
   as it is known today.  Such protection of email identity, may can assist
   in the global control of "spam" and "phishing".

   This document provides a description of DKIM's architecture,
   functionality, deployment architecture and use.
   functionality.  It is intended for those who are adopting,
   developing, or deploying DKIM.  It also will be helpful for those who
   are considering extending DKIM, either into other areas of use or to
   support additional features.  This Overview does not provide
   information on threats to DKIM or email, or details on the
   protocol specifics, which can be found in [RFC4871] and [RFC4686],
   respectively.  The document assumes a background in basic network
   security technology and services.

   It must be stressed that neither this document nor DKIM attempt to
   provide solutions to the world's problems with spam, phish, virii,
   worms, joe jobs, etc.  DKIM provides one basic tool, in what needs to
   be a large arsenal, for improving the safety of Internet mail.
   However, by itself, DKIM is not sufficient to that task and this
   overview does not pursue the issues of integrating DKIM into these
   larger efforts.  Rather, it is a basic introduction to the technology
   and its deployment.

1.1.1.  The DKIM Value Proposition

   The nature and origins of a message are often falsely stated.  As a
   foundation for distinguishing legitimate mail, DKIM provides a means
   of associating a verifiable identity with a message.  Given the
   presence of that identity, a receiver can make decisions about
   further handling of the message, based upon assessments of that
   identity.

   Receivers who successfully verify a signature can use information
   about the signer as part of a program to limit spam, spoofing,
   phishing, or other undesirable behavior.  DKIM does not, itself,
   prescribe any specific actions by the recipient; rather it is an
   enabling technology for services that do.

   These services will typically:

   1.  Verify an identity

   2.  Determine whether the identity is known or unknown

   3.  Determine whether a known identity is trusted

   An attack is made against an organization or against customers of an
   organization.  The name of the organization is linked to particular
   Internet domain names.  One point of leverage used by attackers is
   either to spoof a legitimate domain name, or to use a "cousin" name
   that is similar to one that is legitimate, but is not controlled by
   the target organization.  A DKIM-based accreditation service can
   enforce a basic separation between domains used by such known
   organizations and domains used by others.

   DKIM signatures can be created by a direct handler of a message,
   either as its originator or as an intermediary.  It can also be
   created by an independent service, providing assistance to a handler
   of the message.  Whoever does the signing chooses the domain name to
   be used as the basis for later assessments.  Hence, reputation
   associated with that domain name is the basis for evaluating whether
   to trust the message for delivery.  The owner of the domain name
   being used for a DKIM signature is declaring that they are
   accountable for the message.

   DKIM is intended to be a value-added feature for email.  Mail that is
   not signed by email is handled in the same way as it now is; it
   continues to be evaluated by established analysis and filtering
   techniques.  Over time, widespread DKIM adoption could permit
   degraded handling of messages that are not signed.  However early
   benefits do not require this more-stringent enforcement.

   It is important to be clear about the narrow scope of DKIM's
   capabilities.  It is an enabling technology, intended for use in the
   larger context of determining message legitimacy.  This larger
   context is complex, so that it is easy to assume that a component
   like DKIM, which actually provides only a limited service, instead
   satisfies the broader set of requirements.  A DKIM signature :

   o  Does not offer any assertions about the behaviors of the identity
      doing the signing.

   o  Does not prescribe any specific actions for receivers to take upon
      successful (or unsuccessful) signature verification.

   o  Does not provide protection after signature verification.

   o  Does not protect against re-sending (replay of) a message that
      already has a verified signature; therefore a transit intermediary
      or a recipient can re-post the message in such a way that the
      signature would remain verifiable, although the new recipient(s)
      would not have been specified by the originator.

1.1.2.  Prior Work

   Historical email assessment based on identity has been based on the
   IP Address of a system that sent the message.  The Address is
   obtained via underlying Internet information mechanisms and is
   therefore trusted to be accurate.  Besides having some known security
   weaknesses, the use of Addresses present a number of functional and
   operational problems.  Consequently there is an industry desire to
   use a more stable value that has had better correspondence with
   organizational boundaries.  Domain Names are viewed as satisfying
   this need.

   There have been four previous efforts at standardizing an Internet
   email signature scheme:

   o  Privacy Enhanced Mail (PEM) was first published in 1987.
      [RFC0989]

   o  PEM eventually transformed into MIME Object Security Services in
      1995.  [RFC1848] Today, these two are only of historical interest.

   o  Pretty Good Privacy (PGP) was developed by Phil Zimmermann and
      first released in 1991.  [RFC1991] A later version was
      standardized as OpenPGP.  [RFC2440] [RFC3156]
      [I-D.ietf-openpgp-rfc2440bis]

   o  RSA Security independently developed Secure MIME (S/MIME) to
      transport a PKCS #7 data object.  [RFC3851]

   Development of S/MIME and OpenPGP have continued.  While both have
   achieved a significant user base, neither have achieved ubiquity in
   deployment or use, and their goals differ from those of DKIM.

   To the extent that other message-signing services might have been
   adapted to do the job that DKIM is designed to perform, it was felt
   that re-purposing any of those would be more problematic than
   creating a separate service.  That said, DKIM uses security algorithm
   components that have a long history, including use within some of
   those other messaging security services.

   DKIM has a distinctive approach for distributing and vouching for
   keys.  It uses a key-centric Public Key Infrastructure (PKI) rather
   than the more typical approaches based on a certificate in the styles
   of Kohnfelder (X.509) or Zimmermann (web of trust).  For DKIM, the
   owner of a key asserts its validity, rather than relying on the key
   having a broader semantic implication of the assertion, such as a
   quality assessment of the key's owner.  DKIM treats quality
   assessment as an independent, value-added service, beyond the initial
   work of deploying a verifying signature service.

   Further, DKIM's PKI is supported by adding additional information
   records to the existing Domain Name Service (DNS) [RFC1034], rather
   than requiring deployment of a new query infrastructure.  This
   approach has significant operational advantages.  First, it avoids
   the considerable barrier of creating a new infrastructure; hence it
   leverages a global base of administrative experience and highly
   reliable distributed operation.  Second, the technical aspect of the
   DNS is already known to be efficient.  Any new service would have to
   undergo a period of gradual maturation, with potentially problematic
   early-stage behaviors.  By (re-)using the DNS, DKIM avoids these
   growing pains.

1.1.3.  Internet Mail Background

   Internet Mail has a simple split between the user world, in the form
   of Mail User Agents (MUA), and the transmission world, in the form of
   the Mail Handling Service (MHS) composed of Mail Transfer Agents
   (MTA).  The MHS is responsible for accepting a message from one User
   and delivering it to one or more other users, creating a virtual MUA-
   to-MUA exchange environment.  The first MTA is called the Mail
   Submission Agent (MSA) and the final MTA is called the Mail Delivery
   Agent (MDA).

   Modern Internet Mail service is marked by many independent operators,
   many different components for providing users with service and many
   other components for performing message transfer.  Consequently, it
   is necessary to distinguish administrative boundaries that surround
   sets of functional components.

1.1.3.1.  Administrative Actors

   Operation of Internet Mail services is apportioned to different
   providers (or operators).  Each can be composed of an independent
   ADministrative Management Domain (ADMD).  An ADMD operates with an
   independent set of policies and interacts with other ADMDs according
   to differing types and amounts of trust.  Examples include: an end-
   user operating their desktop client that connects to an independent
   email service, a department operating a submission agent or a local
   Relay, an organization's IT group that operates enterprise Relays,
   and an ISP operating a public shared email service.

   Each of these can be configured into many combinations of
   administrative and operational relationships, with each ADMD
   potentially having a complex arrangement of functional components.
   Figure 1 depicts the relationships among ADMDs.  Perhaps the most
   salient aspect of an ADMD is the differential trust that determines
   its policies for activities within the ADMD, versus those involving
   interactions with other ADMDs.

   Basic components of ADMD distinction include:

      Edge:   Independent transfer services, in networks at the edge of
         the Internet Mail service.

      User:   End-user services.  These might be subsumed under an Edge
         service, such as is common for web-based email access.

      Transit:   These are Mail Service Providers (MSP) offering value-
         added capabilities for Edge ADMDs, such as aggregation and
         filtering.

   Note that Transit services are quite different from packet-level
   transit operation.  Whereas end-to-end packet transfers usually go
   through intermediate routers, email exchange across the open Internet
   is often directly between the Edge ADMDs, at the email level.

   +-------+                           +-------+    +-------+
   | ADMD1 |                           | ADMD3 |    | ADMD4 |
   | ----- |                           | ----- |    | ----- |
   |       |   +---------------------->|       |    |       |
   | User  |   |                       |-Edge--+--->|-User  |
   |  |    |   |                  +--->|       |    |       |
   |  V    |   |                  |    +-------+    +-------+
   | Edge--+---+                  |
   |       |   |    +---------+   |
   +-------+   |    |  ADMD2  |   |
               |    |  -----  |   |
               |    |         |   |
               +--->|-Transit-+---+
                    |         |
                    +---------+

        Figure 1: ADministrative Management Domains (ADMD) Example

   The distinction between Transit network and Edge network transfer
   services is primarily significant because it highlights the need for
   concern over interaction and protection between independent
   administrations.  The interactions between functional components
   within an ADMD are subject to the policies of that domain.

   Common ADMD examples are:

      Enterprise Service Providers:   Operators of an organization's
         internal data and/or mail services.

      Internet Service Providers:   Operators of underlying data
         communication services that, in turn, are used by one or more
         Relays and Users.  It is not necessarily their job to perform
         email functions, but they can, instead, provide an environment
         in which those functions can be performed.

      Mail Service Providers:   Operators of email services, such as for
         end-users, or mailing lists.

1.1.4.  Conventions

   In this document, references to structured fields of a message use a
   two-part dotted notation.  The first part cites the document that
   contains the specification for the field and the second is the name
   of the field.  Hence <RFC2822.From> is the From field in an email
   content header [RFC2822] and <RFC2821.MailFrom> is the address in the
   SMTP "Mail From" command.  [RFC2821]

   This document is being discussed on the DKIM mailing list,
   ietf-dkim@mipassoc.org.

1.2.  Goals

   DKIM seeks to add authentication to the existing email transfer
   infrastructure.  This motivates functional goals about authentication
   and operational goals about integration with the existing email
   service.

1.2.1.  Functional

   Use Domain-level granularity for assurance.   OpenPGP and S/MIME
      apply the end-to-end principle in terms of individual originators
      and recipients, notably using full email addresses.  DKIM seeks
      accountability at the more coarse grain of an organization or,
      perhaps, a department.  A deployed construct that enables this
      granularity is the domain name, to which the signing key record is
      bound.  Further DKIM signing and/or validating may be implemented
      anywhere along the transit path, rather than only in the end
      systems.

   Allow delegation of signing to independent parties.   Different
      parties have different roles in the process of email exchange.
      Some of these parties are easily visible to end users and others
      are primarily visible to operators of the service.  DKIM needs to
      support signing by any of these different parties and needs to
      permit them to sign with any domain name that they deem
      appropriate.  As an example an organization that creates email
      content often delegates portions of its processing or transmission
      to an outsourced group.  DKIM must support this mode of activity,
      in a manner that is not visible to end users.

   Distinguish the core authentication mechanism from its derivative
   uses.   An authenticated identity may be subject to a variety of
      processing policies, either ad hoc or standardized.  The only
      semantics inherent to a DKIM signature is that the signer is
      asserting (some) responsibility for the message.  All other
      mechanisms and meanings are independent of this core service.  One
      such mechanism might assert a relationship between the signing
      identity and the author (<RFC2822.From>) domain identity.  Another
      might specify how to treat an unsigned message with that
      <RFC2822.From> domain.

   Retain ability to have anonymous email.   The ability to send a
      message that does not identify its author is considered to be a
      valuable quality of the current email system that needs to be
      retained.  DKIM is compatible with this goal since it permits an
      email system operator to be authenticated, rather than the content
      author.  Knowing that a mail definitely came from example.com does
      not threaten the anonymity of the user, if it is still possible to
      obtain effectively anonymous accounts at example.com and other
      mail providers.

1.2.2.  Operational

   Make signature transparent to non-supporting recipients.   S/MIME and
      OpenPGP both modify the message body.  Hence, their presence is
      potentially visible to email recipients and their user software
      must be able to process the associated constructs.  In order to
      facilitate incremental adoption, DKIM is designed to be
      transparent to recipients that do not support it.

   Treat verification failure the same as no signature unsigned.
      OpenPGP and S/MIME were both designed for strong cryptographic
      protection.  This included treating verification failure as
      message failure.  As a sub-goal to the requirement for
      transparency, a DKIM signature verifier is to treat messages with
      signatures that fail as if they were unsigned.  Hence the message
      will revert to normal handling, through the receiver's existing
      filtering mechanisms.

   Permit incremental adoption for incremental benefit.   DKIM can
      immediately provide benefits between any two organizations that
      exchange email and implement DKIM.  In the usual manner of
      "network effects", the benefits of DKIM increase dramatically as
      its adoption increases.

      Although it is envisioned that this mechanism will call upon
      independent services to aid in the assessment of DKIM results,
      they are not essential in order to obtain an initial benefit.  For
      example DKIM allows (possibly large) pair-wise sets of email
      providers and spam filtering companies to distinguish mail that is
      associated with a known organization, from mail that might
      deceptively purport to have the affiliation.  This in turn allows
      the development of 'whitelist' schemes whereby authenticated mail
      from a known source with good reputation is allowed to bypass some
      spam filters.  In effect the email receiver is using their set of
      known relationships to generate their own accreditation/reputation
      data.  This works particularly well for traffic between large
      sending providers and large receiving providers.  However it also
      works well for any operator, public or private, that has mail
      traffic dominated by exchanges among a stable set of
      organizations.

   Minimize the amount of required infrastructure.   A new service, or
      an enhancement to an existing service, requires adoption by some
      number of systems, before it can be useful.  The greater the
      number of required adopters, the higher the adoption barrier.
      This becomes particularly serious when adoption is required by
      intermediary -- that is, infrastructure -- service providers.  In
      order to allow early adopters to gain early benefit, DKIM seeks to
      make no changes to the core Internet Mail service and, instead, to
      allow a useful benefit for any signer/verifier pair of
      participants exchanging mail.

      Similarly, DKIM's reliance on the Domain Name Service greatly
      reduces the amount of new administrative infrastructure that must
      be deployed over the open Internet.

   Permit wide range of deployment choices.   It should be possible to
      implement DKIM at a variety of places within an organization's
      email service.  This permits the organization to choose how much
      or how little they want DKIM to be part of their service, rather
      than part of a more localized operation.

1.3.  Function

   DKIM has a very constrained set of capabilities, primarily targeting
   email while it is in transit, from an originator to a set of
   recipients.  It creates the ability to associate verifiable
   information with a message, especially a responsible identity.  When
   a message is not signed, DKIM permits the identity of the sender to
   be used for obtaining information about their signing practices.

1.3.1.  The Basic Signing Service

   With the DKIM signature mechanism, a signer associates a domain name
   with an address, performs digital signing on the message, and records
   signature information in a DKIM header field.  A verifier obtains the
   domain name from the DKIM header field, queries for a public key
   associated with the name, and verifies the signature.

   DKIM permits any domain name to be use for signing, and supports
   extensible choices for various algorithms.  As is typical for
   Internet standards, there is a core set of algorithms required to be
   supported by all implementations.  This ensures an initial ability to
   interoperate.

   DKIM permits restricting the use of a signature key to particular
   types of services, such as only for email.  This is helpful when
   delegating signing authority, such as to a particular department or
   to a third-party outsourcing service.

   With DKIM the signer MUST explicitly list the headers that are
   signed.  By choosing the minimal set of headers needed the signature
   is likely to be considerably more robust against the handling
   vagaries of intermediary MTAs.

1.3.2.  Characteristics of a DKIM signature

   A DKIM signature covers the message body and selected header fields.
   The signer computes a hash of the selected header fields and another
   hash of the body.  The signer then uses a private key to
   cryptographically encode this information, along with other signing
   parameters.  Signature information is placed into a new [RFC2822]
   header field of the message.

1.3.3.  The Selector construct

   A signature is associated with a domain name, as specified in the
   "d=" DKIM parameter.  That domain name is the complete identity used
   for making assessments about the signer.  However this name is not
   sufficient for making a query to obtain the key needed to verify the
   signature.

   A single domain can use multiple signing keys and/or multiple
   signers.  To support this, DKIM identifies a particular signature as
   a combination of the domain name and an added field, called the
   "selector".  Both of these are coded into the DKIM-Signature header
   field.

   It must be stressed that the selector is not part of the domain name
   that is used for making assessments.  Rather, the selector is
   strictly reserved for use in administering keys that are associated
   with the domain name.  If the selector becomes part of a name
   assessment mechanism, then there is no remaining mechanism for making
   a transition from an old, or compromised, key to a new one.

   Signers do have the need for supporting multiple assessments about
   their organization, such as to distinguish one type of message from
   another, or one portion of the organization from another.  To permit
   assessments that are independent, an organization should use
   different sub-domains in the "d=" parameter, such as
   "transaction.example.com" versus "newsletter.example.com", or
   productA.example.com versus productB.example.com.

1.3.4.  Verification

   After a message has been signed, any agent in the message transit
   path can choose to verify the signature, to determine that the
   signing identity took responsibility for the message.  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.  Typically, verification will be
   done by an agent in the ADMD of the message recipient.

1.4.  Service Architecture

   The DKIM service is divided into components that can be performed
   using different, external services, such as for key retrieval.
   However the basic DKIM signing specification defines an initial set
   of these services, in order to ensure a basic level of
   interoperability.

                           |
                           |- RFC2822 Message
                           V
            +------------------------------+
            | ORIGINATING OR RELAYING ADMD |
            |                              |
        +..>| Sign Message                 |
        .   +--------------+---------------+
        .                  |
        .private           |
    +---+---+              |               +-----------+
    |  Key  |              |               |  Sender   |
    | Store |          [Internet]          | Practices |
    +---+---+              |               +-----+-----+
        .public            |                     .
        .                  V                     .
        .   +------------------------------+     .
        .   | RELAYING OR DELIVERING ADMD  |     .
        .   |                              |     .
        .   | Message Signed?              |     .
        .   +-------+----------------+-----+     .
        .           |yes             |no         .
        .           V                V           .
        .      +-----------+     +-----------+   .
        +.....>| Verify    | +..>| Check     |<..+
               | Signature | |   | Practices |
               +---+-----+-+ |   +---+-------+
                   |     |   |       |
                   |     +---+       |
                   |pass  fail       |
                   V                 |
               +--------+            |
      +.......>| Assess |            |
      .        | Signer |            |
      .        +---+----+            |
      .  assessment|                 |
      .            +------+   +------+
      .                   |   |
    +-+----------+         V   V
    | Reputation |    +-----------+
    +-----+------+    | Message   |
                      | Filtering |
                      | Engine    |
                      +-----------+>

                    Figure 2: to DKIM Service Architecture

   As shown or email, or details on the protocol
   specifics, which can be found in [RFC4871] and [RFC4686],
   respectively.  The document assumes a background in basic network
   security technology and services.

   Neither this document nor DKIM attempt to provide solutions to the Figure,
   world's problems with spam, phishing, virii, worms, joe jobs, etc.
   DKIM provides one basic message processing is divided between
   signing tool, in what needs to be a large arsenal,
   for improving basic trust in the message, verifying Internet mail service.  However by
   itself, DKIM is not sufficient to that task and this Overview does
   not pursue the signature or determining whether issues of integrating DKIM into these larger efforts,
   beyond a
   signature was required, simple reference within a system diagram.  Rather, it is a
   basic introduction to the technology and then making further decisions its use.

1.1.  Prior Work

   Historical email assessment based upon on identity has been based on the results.  Signing may
   IP Address of a system that sent the message.  The Address is
   obtained via underlying Internet information mechanisms and is
   therefore trusted to be performed by accurate.  Besides having some known security
   weaknesses, the use of Addresses present a component number of functional and
   operational problems.  Consequently there is an industry desire to
   use a more stable value that has better correspondence to
   organizational boundaries.  Domain Names are viewed as satisfying
   this need.

   There have been four previous efforts at standardizing an Internet
   email signature scheme:

   o  Privacy Enhanced Mail (PEM) was first published in 1987.
      [RFC0989]

   o  PEM eventually transformed into MIME Object Security Services
      (MOSS) in 1995.  [RFC1848] Today, these two are only of the ADMD
   that creates the message, and/or within any ADMD, along the relay
   path.  The signer uses the appropriate private key.

   Verification may be performed historical
      interest.

   o  Pretty Good Privacy (PGP) was developed by any functional component along the
   relay Phil Zimmermann and delivery path.  Verifiers retrieve the public key based
   upon the parameters stored
      first released in the message.  The figure shows the
   verified identity 1991.  [RFC1991] A later version was
      standardized as being used OpenPGP.  [RFC2440] [RFC3156]
      [I-D.ietf-openpgp-rfc2440bis]

   o  RSA Security independently developed Secure MIME (S/MIME) to assess an associated reputation,
   but it could be applied for other tasks, such as management tracking
      transport a PKCS #7 data object.  [RFC3851]

   Development of mail.

   Note that S/MIME and OpenPGP have continued.  While both have
   achieved a failed signature causes significant user base, neither have achieved ubiquity in
   deployment or use, and their goals differ from those of DKIM.

   To the message extent that other message-signing services might have been
   adapted to be treated in do the
   same manner as one job that DKIM is unsigned.  Unsigned messages prompt designed to perform, it was felt
   that re-purposing any of those would be more problematic than
   creating a
   query separate service.  That said, DKIM uses security algorithm
   components that have a long history, including use within some of
   those other messaging security services.

   DKIM has a distinctive approach for any published "sender practices" information, as an aid in
   determining whether distributing and vouching for
   keys.  It uses a key-centric Public Key Infrastructure (PKI) rather
   than the sender information has been used without
   authorization. more typical approaches based on a certificate in the styles
   of Kohnfelder (X.509) or Zimmermann (web of trust).  For signature verification and for DKIM, the assessment
   owner of unsigned
   messages, a key asserts its validity, rather than relying on the results key
   having a broader semantic implication of these processes are treated as additional
   input to the receiver's filtering engine.  The engine determines
   message disposition, assertion, such as whether to deliver it.

2.  Deployment and Operation a
   quality assessment of the key's owner.  DKIM Base

2.1.  Development

2.1.1.  Coding Criteria for Cryptographic Applications

   Correct implementation treats quality
   assessment as an independent, value-added service, beyond the initial
   work of deploying a cryptographic algorithm verifying signature service.

   Further, DKIM's PKI is a necessary
   but not a sufficient condition for the coding of cryptographic
   applications.  Coding of cryptographic libraries requires close
   attention to security considerations that are unique to cryptographic
   applications.

   In addition to the usual security coding considerations, such as
   avoiding buffer or integer overflow and underflow, implementers
   should pay close attention supported by adding additional information
   records to management of cryptographic private
   keys and session keys, ensuring that these are correctly initialized
   and disposed of.

   Operating system mechanisms that permit the confidentiality existing Domain Name System (DNS) [RFC1034], rather
   than requiring deployment of
   private keys to be protected against other processes SHOULD be used
   when available.  In particular, great care MUST be taken when
   releasing memory pages to a new query infrastructure.  This
   approach has significant operational advantages.  First, it avoids
   the operating system to ensure that private
   key information is not disclosed to other processes.

   On multiple processor and dual core architectures, certain
   implementations considerable barrier of public key algorithms such as RSA may be
   vulnerable to creating a timing analysis attack.

   Support for cryptographic hardware providing key management
   capabilities is strongly encouraged.  In addition to offering
   performance benefits, many cryptographic hardware devices provide
   robust and verifiable management new infrastructure; hence it
   leverages a global base of private keys.

   Fortunately appropriately designed and coded cryptographic libraries
   are available for most operating system platforms under license terms
   compatible with commercial, open source administrative experience and free software license
   terms.  Use highly
   reliable distributed operation.  Second, the technical aspect of standard cryptographic libraries the
   DNS is strongly
   encouraged.  These already known to be efficient.  Any new service would have been extensively tested, reduce development
   time and support to
   undergo a wide range period of cryptographic hardware.

2.1.2.  Signer

   Signer implementations SHOULD provide gradual maturation, with potentially problematic
   early-stage behaviors.  By (re-)using the DNS, DKIM avoids these
   growing pains.

1.2.  Discussion Venue

   NOTE TO RFC EDITOR:   This "Discussion Venue" section is to be
      removed prior to publication.

   This document is being discussed on the DKIM mailing list,
   ietf-dkim@mipassoc.org.

2.  Internet Mail Background

   Internet Mail has a convenient means simple split between the user world, in the form
   of
   generating DNS key records corresponding to Mail User Agents (MUA), and the signer configuration.
   Support for automatic insertion transmission world, in the form of key records into
   the DNS Mail Handling Service (MHS) composed of Mail Transfer Agents
   (MTA).  The MHS is also
   highly desirable.  If supported however, such mechanism(s) MUST be
   properly authenticated.

   A means responsible for accepting a message from one user,
   the author, and delivering it to one or more other users, the
   recipients.  This creates a virtual MUA-to-MUA exchange environment.
   The first component of verifying that the signer configuration MHS is compatible with called the signature policy Mail Submission Agent
   (MSA) and the last is also highly desirable.

   Disclosure called the Mail Delivery Agent (MDA).

   An email Mediator is both an inbound MDA and outbound MSA.  It takes
   delivery of a private signature key component to a third party
   allows that third party to impersonate message and reposts it for further distribution,
   retaining the sender.  The protection of
   private signature key data original From header field.  A mailing list is therefore a critical concern.  Signers
   SHOULD support use common
   example of cryptographic hardware providing key management
   features. a Mediator

   The import modern Internet Mail service is marked by many independent
   operators, many different components for providing users with service
   and export many other components for performing message transfer.
   Consequently, it is necessary to distinguish administrative
   boundaries that surround sets of private keys, and the ability functional components, which are
   subject to generate coherent operational policies.

   As expanded on below, every MSA is a
   Certificate Signing Request (CSR) candidate for certificate registration are
   highly desirable.

2.2.  Email Infrastructure Agents

   It signing using
   DKIM, and every MDA is expected that the most common venue for a candidate for doing DKIM implementation
   will verification.

2.1.  Administrative Management Domain (ADMD)

   Operation of Internet Mail services is apportioned to different
   providers (or operators).  Each can be within the infrastructure composed of an organization's email service,
   such as a department or a boundary MTA.

      Outbound: independent
   ADministrative Management Domain (ADMD).  An MSA or Outbound MTA should allow for the automatic
         verification of the MTA configuration such that the MTA can
         generate an operator alert if it determines that it is (1) ADMD operates with an
         edge MTA,
   independent set of policies and (2) configured to send email messages that do not
         comply interacts with the published DKIM sending policy.

         An outbound MTA should be aware that users may employ MUAs that
         add their own signatures and be prepared to take steps
         necessary other ADMDs according
   to ensure that the message sent is in compliance with
         the advertised email sending policy.

      Inbound:   An inbound MTA or differing types and amounts of trust.  Examples include: an MDA that does not support DKIM
         should avoid modifying messages in ways end-
   user operating their desktop client that prevent
         verification by other MTAs, or MUAs connects to which the message may be
         forwarded.

         An inbound MTA an independent
   email service, a department operating a submission agent or a local
   Relay, an MDA may incorporate organization's IT group that operates enterprise Relays,
   and an indication ISP operating a public shared email service.

   Each of the
         verification results these can be configured into the message, such as using an
         Authentication-Results header.
         [I-D.kucherawy-sender-auth-header]

      Intermediaries:   An email intermediary is both an inbound many combinations of
   administrative and
         outbound MTA.  Each operational relationships, with each ADMD
   potentially having a complex arrangement of functional components.
   Figure 1 depicts the requirements outlined in relationships among ADMDs.  Perhaps the
         sections relating to MTAs apply.  If most
   salient aspect of an ADMD is the intermediary modifies
         a message in a way differential trust that breaks determines
   its policies for activities within the signature, ADMD, versus those involving
   interactions with other ADMDs.

   Basic types of ADMDs include:

      Edge:   Independent transfer services, in networks at the intermediary

         +  SHOULD deploy abuse filtering measures on edge of
         the inbound mail, Internet Mail service.

      User:   End-user services.  These might be subsumed under an Edge
         service, such as is common for web-based email access.

      Transit:   These are Mail Service Providers (MSP) offering value-
         added capabilities for Edge ADMDs, such as aggregation and

         +  MAY remove all signatures
         filtering.

   Note that will be broken

         In addition Transit services are quite different from packet-level
   transit operation.  Whereas end-to-end packet transfers usually go
   through intermediate routers, email exchange across the intermediary MAY:

         +  Verify open Internet
   is often directly between the message signature prior to modification.

         +  Incorporate an indication of Edge ADMDs, at the verification results into email level.

   +--------+                            +--------+    +--------+
   | ADMD#1 |                            | ADMD#3 |    | ADMD#4 |
   | ------ |                            | ------ |    | ------ |
   |        |   +----------------------->|        |    |        |
   | User   |   |                        |--Edge--+--->|--User  |
   |  |     |   |                   +--->|        |    |        |
   |  V     |   |                   |    +--------+    +--------+
   | Edge---+---+                   |
   |        |   |    +----------+   |
   +--------+   |    |  ADMD#2  |   |
                |    |  ------  |   |
                |    |          |   |
                +--->|-Transit--+---+
                     |          |
                     +----------+

        Figure 1: ADministrative Management Domains (ADMD) Example

   In Figure 1, ADMD numbers 1 and 2 are candidates for doing DKIM
   signing, and ADMD numbers 2, 3 and 4 are candidates for doing DKIM
   verification.

   The distinction between Transit network and Edge network transfer
   services is primarily significant because it highlights the message, such as using need for
   concern over interaction and protection between independent
   administrations.  The interactions between functional components
   within an Authentication-Results header.
            [I-D.kucherawy-sender-auth-header]

         +  Sign the modified message including the verification results
            (e.g., ADMD are subject to the Authentication-Results header).

2.3.  Filtering

   Developers policies of filtering schemes designed to accept DKIM
   authentication results as input should be aware that their
   implementations will be subject to counter-attack by email abusers.
   The efficacy domain.

   Common ADMD examples are:

         Enterprise Service Providers:

            Operators of a filtering scheme cannot therefore be determined an organization's internal data and/or mail
            services.

         Internet Service Providers:

            Operators of underlying data communication services that, in
            turn, are used by
   reference to static test vectors alone; resistance to counter attack
   must also be considered.

   Naive learning algorithms that only consider the presence one or absence
   of a verified DKIM signature, without considering more information
   about the message, are vulnerable Relays and Users.  It is not
            necessarily their job to perform email functions, but they
            can, instead, provide an attack environment in which a spammer those
            functions can be performed.

         Mail Service Providers:

            Operators of email services, such as for end-users, or
   other malefactor signs all their mail, thus creating a large negative
   value
            mailing lists.

2.2.  DKIM Placement within an ADMD

   It is expected that the most common venue for presence of a DKIM signature in the hope of discouraging
   widespread use.

   If heuristic algorithms are employed, they should implementation
   will be trained on
   feature sets that sufficiently reveal within the internal structure infrastructures of the
   DKIM responses.  In particular the algorithm should consider the
   domains purporting to claim responsibility for the signature, rather
   than originating organization's
   outbound service and and the existence of receiving organization's inbound
   service, such as a signature department or not.

   Unless a scheme can correlate the boundary MTA.  DKIM signature with accreditation can be
   implemented in an author's or reputation data, the presence of a DKIM signature SHOULD recipient MUA, but this is expected to
   be
   ignored.

2.4.  DNS Server

   At less typical, since it has higher administration and support
   costs.

   A Mediator, such as a minimum, mailing list, often can re-post a DNS server that handles queries for DKIM key records
   must allow message
   without breaking the server administrators to DKIM signature.  Furthermore it can add free-form TXT records.
   It would, of course, its own
   signature.  This can be better for provide them with a structured
   form, to support added by the DKIM-specific fields.

2.5.  Deployment

   This section describes Mediator software itself, or by
   any outbound component in the basic steps for introducing DKIM into an
   organization's email service operation. Mediator's ADMD.

3.  The considerations are
   divided between the generating DKIM signatures (Signing) Value Proposition

   The nature and the
   processing origins of messages that contain a DKIM signature (Verifying).

2.5.1.  Key Management

   Selectors  Selectors message are assigned according to the administrative
      needs of the signing domain, such as for rolling over to often falsely stated.  As a new key
      or
   foundation for delegating distinguishing legitimate mail, DKIM provides a means
   of associating a verifiable identity with a message.  Given the right to authenticate
   presence of that identity, a portion receiver can make decisions about
   further handling of the
      namespace to a trusted third party.

         Examples include:   jun2005.eng._domainkey.example.com
            widget.promotion._domainkey.example.com

         NOTE:   It is intended that message, based upon assessments of DKIM identities be
            based on the domain name, and not include the selector.
            This permits the selector to be used only for key
            administration, rather than having an effect on reputation
            assessment.

2.5.2.  Signing

   Creating messages that have DKIM signatures requires
   identity.

   Receivers who successfully verify a modification
   to only two portions of signature can use information
   about the email service:

   o  Addition of relevant DNS information.

   o  Addition signer as part of the signature by a trusted module within the
      organization's email handling service.

   The signing module uses the appropriate private key program to create a
   signature.  The means limit spam, spoofing,
   phishing, or other undesirable behavior.  DKIM does not, itself,
   prescribe any specific actions by which the signing module obtains the private
   key is not specified by DKIM.  Given that DKIM is intended for use
   during email transit, recipient; rather than for long-term storage, it is
   expected an
   enabling technology for services that keys do.

   These services will be changed regularly.  Clearly this means
   that key information should not be hard-coded into software.

2.5.2.1.  DNS Records

   A receiver attempting to verify a DKIM signature must obtain typically:

   1.  Verify an identity

   2.  Determine whether the
   public key that identity is associated with the signature for that message. known or unknown

   3.  Determine whether a known identity is trusted

   The DKIM-Signature header role of DKIM is in the message will specify first two of these; DKIM is an enabler for
   the basic
   domain third.

   An attack is made against an organization or against customers of an
   organization.  The name doing the signing and of the selector organization is linked to be particular
   Internet domain names.  One point of leverage used for the
   specific public key.  Hence, the relevant
   <selector>._domainkey.<domain-name> DNS record needs by attackers is
   either to contain spoof a
   DKIM-related resource record (RR) that provides the public key
   information.

   The administrator of the zone containing the relevant legitimate domain name, or to use a "cousin" name
   adds this information.  Initial DKIM DNS information
   that is contained
   within TXT RRs.  DNS administrative software varies considerably in
   its abilities similar to add new types of DNS records.

2.5.2.2.  Signing Module

   The module doing signing one that is legitimate, but is not controlled by
   the target organization.  A DKIM-based accreditation service can be placed anywhere within an
   organization's trusted Administrative Management Domain (ADMD);
   common choices are expected to be department-level posting
   enforce a basic separation between domains used by such known
   organizations and
   delivering agents, domains used by others.

   DKIM signatures can be created by a direct handler of a message,
   either as well its originator or as boundary MTAs an intermediary.  It can also be
   created by an independent service, providing assistance to a handler
   of the message.  Whoever does the open Internet.
   (Note that it is entirely acceptable for MUAs to perform signing and
   verification.)  Hence chooses the choice among domain name to
   be used as the modules depends upon
   software development and administrative overhead tradeoffs.  One
   perspective basis for later assessments.  Hence, reputation
   associated with that helps resolve this choice domain name is the difference between basis for evaluating whether
   to trust the flexibility message for delivery.  The owner of use by systems at (or close to) the MUA, versus domain name
   being used for a DKIM signature is declaring that they are
   accountable for the centralized control message.

   DKIM is intended to be a value-added feature for email.  Mail that is more easily obtained
   not signed by implementing
   the mechanism "deeper" into DKIM is handled in the organization's email infrastructure,
   such same way as at its boundary MTA.

2.5.2.3.  Signing Policies and Practices

   Every organization (ADMD) will have its own policies and practices
   for deciding when it was, before DKIM
   was defined; it continues to sign messages and with what domain name be evaluated by established analysis and key
   (selector).  Examples include signing all mail, signing mail from
   particular email addresses, or signing mail from particular sub-
   domains.  Given
   filtering techniques.  Over time, widespread DKIM adoption could
   permit more strict handling of messages that are not signed.  However
   early benefits do not require this variability, and the likelihood that signing
   practices will change over time, it will be useful probably do not warrant this.

   It is important to have these
   decisions represented in some sort of configuration information,
   rather than being more deeply coded into the signing software.

2.5.3.  Verifying

2.5.3.1.  Verifier

   Verifiers SHOULD treat be clear about the result narrow scope of the verification step as DKIM's
   capabilities.  It is an
   input to enabling technology, intended for use in the
   larger context of determining message evaluation process rather than as providing a
   final decision.  The knowledge legitimacy.  This larger
   context is complex, so that a message it is authentically sent
   by easy to assume that a domain does component
   like DKIM, which actually provides only a limited service, instead
   satisfies the broader set of requirements.  A DKIM signature:

   o  Does not say much offer any assertions about the legitimacy behaviors of the message,
   unless the characteristics of identity
      doing the domain claiming responsibility are
   known.

   In particular, verifiers SHOULD NOT automatically assume that an
   email message that does signing.

   o  Does not contain a signature, or that contains a prescribe any specific actions for receivers to take upon
      successful signature that does verification.

   o  Does not verify, is forged.  Verifiers should treat a
   signature that fails to verify the same as if no provide protection after signature were
   present.

   Verification is performed within an ADMD that wishes to make
   assessments based upon the DKIM signature's domain name.  Any
   component within the ADMD verification.

   o  Does not protect against re-sending (replay of) a message that handles messages, whether in
      already has a verified signature; therefore a transit intermediary
      or being delivered, a recipient can do the verifying and subsequent assessments.
   Verification and assessment might occur within re-post the same software
   mechanism, message in such as a Boundary MTA, or an MDA.  Or they may be
   separated, such as having verification performed by the Boundary MTA
   and assessment performed by the MDA.

   As with the signing process, choice of service venues for
   verification and assessment -- such as filtering or presentation to
   the recipient user -- depend on trade-offs for flexibility, control,
   and operational ease.  An added concern is way that the linkage between
   verification and assessment entails essential trust:
      signature would remain verifiable, although the assessment
   module MUST new recipient(s)
      would not have a strong basis for believing that been specified by the verification
   information is correct.

2.5.3.2.  DNS Client author.

4.  The primary means Role of publishing Trust

   As mentioned above, DKIM key information, initially, lets you verify the identity of a signer and
   is
   initially through DNS TXT records.  Some DNS client software might
   have problems obtaining these records; as DNS client software
   improves this will an enabler for determining whether a now-known identity is
   trusted; it does not be itself provide that determination.  Deciding
   whether a concern.

2.5.3.3.  Boundary Enforcement

   In order for non-known identity can be trusted must be handled by
   accreditation and reputation services that are themselves trustable.

   An accreditation service provides an assessment module to trust the information it
   receives about verification (e.g., Authentication-Results headers),
   it MUST eliminate verification information originating from outside of a sender's
   trustworthiness on behalf of the ADMD in which sender.  They reflect the statement
   "this signer says they are good and I concur with that statement."
   Accreditation services are almost always network-based.

   A reputation service provides an assessment mechanism operates.  As of a matter sender's
   trustworthiness on behalf of
   friendly practice, it is equally important to make sure that
   verification information generated within the ADMD not escape outside
   of it.

   In most environments, receiver.  They reflect the easiest way to enforce
   statements "based on their past history or some private knowledge
   about them, this is signer can be trusted" or "not trusted."  Reputation
   services can be network-based or be based on local white lists and
   black lists.

5.  DKIM Goals

   DKIM adds an end-to-end authentication mechanism to place
   modules in the receiving existing
   email transfer infrastructure.  This motivates functional goals about
   authentication and sending Boundary MTA(s) that strip any operational goals about integration with the
   existing verification information.

2.5.4.  Mail User Agent

   DKIM is designed to support deployment email service.

5.1.  Functional Goals

5.1.1.  Use Domain-level granularity for assurance.

   OpenPGP and use S/MIME apply the end-to-end principle in terms of
   individual originators and recipients, notably using full email components
   other than an MUA.  However an MUA MAY also implement
   addresses.  DKIM features
   directly.

      Outbound:   If seeks accountability at the more coarse granularity
   of an MUA organization or, perhaps, a department.  An existing Internet
   service construct that enables this granularity is configured the Domain Name
   [RFC1034], to send email directly, which the signing key record is bound.  Further DKIM
   signing and/or validating can be implemented anywhere along the
   transit path, rather than relayed through an outbound MSA, only in the MUA SHOULD be
         considered as if it were an outbound MTA for end systems or only in the purposes
   boundary MTA.

5.1.2.  Allow delegation of
         DKIM.  An MUA MAY support signing even if mail is to be relayed
         through an outbound MSA.  In this case independent parties.

   Different parties have different roles in the signature applied by process of email
   exchange.  Some are easily visible to end users and others are
   primarily visible to operators of the MUA may be in addition service.  DKIM needs to support
   signing by any MSA signature.

      Inbound:   An MUA MAY rely on a report of a DKIM signature
         verification these different parties and needs to permit them to
   sign with any domain name that took place at some point in the inbound MTA
         path (e.g., they deem appropriate (and for which
   they are authorized.)  As an example an Authentication-Results header), organization that creates
   email content often delegates portions of its processing or
   transmission to an MUA MAY
         perform outsourced group.  DKIM signature verification directly.  A verifying MUA
         SHOULD allow for the case where mail is modified in the inbound
         MTA path.

2.5.5.  Transition strategy

   Deployment supports this mode of
   activity, in a new signature algorithm without a 'flag day' requires
   a transition strategy such manner that signers and verifiers can phase in
   support for the new algorithm independently, and (if necessary) phase
   out support for is not visible to end users.

5.1.3.  Distinguish the old algorithm independently.

   [Note: this section assumes that a security policy core authentication mechanism exists.
   It is from its
        derivative uses.

   An authenticated identity can be subject to change.]

   DKIM achieves these requirements through two features: First a signed
   message may contain multiple signatures created by the same signer.
   Secondly the security policy layer allows the signing algorithms in
   use variety of processing
   policies, either ad hoc or standardized.  The only semantics inherent
   to be advertised, thus preventing a downgrade attack.

2.5.5.1.  Signer transition strategy

   Let DKIM signature is that the old signing algorithm be A, signer is asserting (some)
   responsibility for the new signing algorithm be B.
   The sequence message.  All other mechanisms and meanings
   are independent of events by which this core service.  One such mechanism might
   assert a Signer may introduce relationship between the new signing algorithm B, without disruption of service to legacy
   verifiers, is identity and the author, as follows:

   1.  Signer signs
   specified in the From header field's domain identity[RFC2822].
   Another might specify how to treat an unsigned message with algorithm A

       A.  Signer advertises that it signs with algorithm A

   2.  Signer signs messages twice, with both algorithm A and algorithm
       B

       A. From
   field domain.

5.1.4.  Retain ability to have anonymous email.

   The signer tests new signing configuration

       B.  Signer advertises that it signs with algorithm A and
           algorithm B

   3.  Signer determines that support for Algorithm A is no longer
       necessary

   4.  Signer determines ability to send a message that support for algorithm A does not identify its author is
   considered to be withdrawn

       A.  Signer removes advertisement for Algorithm A

       B.  Signer waits for cached copies a valuable quality of earlier signature policy the current email service that
   needs to
           expire

       C.  Signer stops signing be retained.  DKIM is compatible with Algorithm A

2.5.5.2.  Verifier transition strategy

   The actions of the verifier are independent of the signer's actions
   and do not need this goal since it
   permits an email system operator to be performed in a particular sequence.  The
   verifier may make authenticated, rather than the
   content author.  Knowing that a decision message definitely came from
   example.com does not threaten the anonymity of the user who authored
   it, if it is still possible to cease accepting algorithm A without
   first deploying support obtain effectively anonymous accounts
   at example.com.

5.2.  Operational Goals

5.2.1.  Treat verification failure the same as no signature present.

   OpenPGP and S/MIME were both designed for algorithm B. Similarly strong cryptographic
   protection.  This included treating verification failure as message
   failure.  As a verifier may be
   upgraded to support algorithm B without requiring algorithm A sub-goal to be
   withdrawn.  The decisions of the requirement for transparency, a DKIM
   signature verifier must make are therefore:

   o  The verifier MAY change the degree of confidence associated is to treat messages with
      any signature at any time, including determining signatures that fail as
   if they were unsigned.  Hence the message will revert to normal
   handling, through the receiver's existing filtering mechanisms.
   Thus, a given
      signature algorithm provides sender cannot apply a limited assurance of authenticity
      at broken signture and force a given key strength.

      *  A verifier MAY evaluate signature records in message to
   be treated any order it
         chooses, including using differently than if the signature algorithm weren't there.

5.2.2.  Make signatures transparent to choose the
         order.

   o  The verifier MAY make a determination that Algorithm A does not
      offer a useful level of security, or that the cost of verifying non-supporting recipients.

   S/MIME and OpenPGP both modify the signature message body.  Hence, their
   presence is less than potentially visible to email recipients and their user
   software needs to process the value of doing so.

      * associated constructs.  In this case the verifier would ignore signatures created using
         algorithm A and references order to
   facilitate incremental adoption, DKIM is designed to algorithm A in policy records
         would be treated as if the algorithm were not implemented.

   o  The verifier MAY decide transparent
   to add recipients that do not support for additional it.  A DKIM signature
      algorithms at any time.

      *  The verifier MAY add support cannot "get
   in the way" for algorithm B at any time.

2.5.6.  Migrating from DomainKeys

2.5.6.1.  Signing

      DNS Records: such recipients.

5.2.3.  Permit incremental adoption for incremental benefit.

   DKIM is upwardly compatible with existing
         DomainKeys (DK) [RFC4870] DNS records, so can immediately provide benefits between any two organizations
   that a DKIM module
         does not automatically require additional DNS administration!
         However DKIM has enhanced exchange email and implement DKIM.  In the usual manner of
   "network effects", the DomainKeys DNS key record format
         by adding several additional optional parameters.

      Boundary MTA:   The principle use benefits of DomainKeys is at Boundary
         MTAs.  Because no operational transition is ever instantaneous, DKIM increase dramatically as its
   adoption increases.

   Although it is not adviseable for existing DomainKeys signers to switch envisioned that this mechanism will call upon
   independent services to aid in the assessment of DKIM without continuing results, they
   are not essential in order to perform DomainKeys signing.  A
         signer should add a obtain initial benefit.  For example
   DKIM signature allows (possibly large) pair-wise sets of email providers and
   spam filtering companies to a message distinguish mail that also has a
         DomainKeys signature, until such time as DomainKeys receive-
         side support is sufficiently reduced.  With respect to signing
         policies, associated with
   a reasonable, initial approach is known organization, from mail that might deceptively purport to use DKIM
         signatures in
   have the same way as DomainKeys signatures are already
         being used.

2.5.6.2.  Verifying

      DNS Client:   DNS queries for affiliation.  This in turn allows the DKIM key record, use development of
   "whitelist" schemes whereby authenticated mail from a known source
   with good reputation is allowed to bypass some spam filters.

   In effect the same
         Domain Name naming conventions as were used email receiver is using their set of known
   relationships to generate their own reputation data.  This works
   particularly well for DomainKeys, traffic between large sending providers and
   large receiving providers.  However it also works well for any
   operator, public or private, that has mail traffic dominated by
   exchanges among a stable set of organizations.

5.2.4.  Minimize the same basic record format.  No changes amount of required infrastructure

   A new service, or an enhancement to the DNS client
         should be required.

      Verifying module:   See the section on Signing above.

2.6.  On-going Operations

   This section describes the basic steps for operation an existing service, requires
   adoption by some number of email systems
   that use DKIM, after the capability has initially been deployed. systems, before it can be useful.  The
   primary considerations are:

   o  the upkeep of the selector files, and

   o
   greater the security number of required adopters, the private keys.

2.6.1.  DNS Signature Record Installation Considerations

   Even with use of higher the DNS, one challenge is that DNS record management adoption
   barrier.  This becomes particularly serious when adoption is usually operated required
   by an administrative staff intermediary -- that is different from
   those who operate an organization's email service. is, infrastructure -- service providers.  In
   order to
   ensure that allow early adopters to gain early benefit, DKIM DNS records are accurate, this imposes makes no
   changes to the core Internet Mail service and, instead, can provide a requirement
   useful benefit for careful coordination between any signer/verifier pair of participants
   exchanging mail.  Similarly, DKIM's reliance on the two operations groups.

   The key point to remember is Domain Name
   System greatly reduces the amount of new administrative
   infrastructure that is need, across the DNS open Internet.

5.2.5.  Permit wide range of deployment choices.

   DKIM selectors WILL and
   SHOULD can be changed over time.  Some reasons for changing deployed at a variety of places within an organization's
   email service.  This permits the organization to choose how much or
   how little they want DKIM
   selectors are well understood, while others are still theoretical.
   There are several schemes that may to be used part of their service, rather than
   part of a more localized operation.

6.  DKIM Function

   DKIM has a very constrained set of capabilities, primarily targeting
   email while it is in transit, from an author to determine a set of recipients.
   It creates the policies
   for changing DKIM selectors:

   o  time based

   o  associations ability to associate verifiable information with clusters of servers

   o a
   message, especially a responsible identity.  When a message is not
   signed, DKIM permits the use identity of third party signers
   o  security considerations

2.6.1.1.  Time Basis and Security Considerations

   The reason for changing the selector periodically is usually related sender to be used for
   obtaining information about their signing practices.

6.1.  The Basic Signing Service

   With the security exposure of DKIM signature mechanism, a system.  When signer chooses a signing
   identity based on their domain name, performs digital signing on the potential exposure of
   message, and records signature information in a DKIM header field.  A
   verifier obtains the private keys associated with domain name and the "selector" from the DKIM selector have reached
   sufficient levels,
   header field, queries for a public key associated with the selector should be changed.  (It is unclear
   currently what kinds of metrics can be used to aid in deciding when name, and
   verifies the exposure has reached sufficient levels signature.

   DKIM permits any domain name to warrant changing the
   selector.)

   For example,

   o  Selectors should be changed more frequently on systems that are
      widely exposed, than on systems that are less widely exposed.  For
      example, a gateway system that has numerous externally-accessible
      services running on it, used for signing, and supports
   extensible choices for various algorithms.  As is typical for
   Internet standards, there is more widely exposed than one that ONLY
      runs a mail server.

   o  Selectors should be changed more frequently on operating systems core set of algorithms that all
   implementations are under wide attack.

   o  While required to support, in order to guarantee basic
   interoperability.  This ensures an initial ability to interoperate.

   DKIM permits restricting the use of DKIM information is transient, keys with
      sufficient exposure do become stale and should be changed.

   o  Whenever you make a substantial system change, signature key to particular
   types of services, such as only for email.  This is helpful when
   delegating signing authority, such as bringing up to a new server, particular department or making
   to a major operating system change, you
      should consider changing the selector.

   o  Whenever there is either suspicion or evidence of the compromise
      of third-party outsourcing service.

   With DKIM the system or signer explicitly lists the private keys, you should change headers that are signed.
   By choosing the selector.

2.6.1.2.  Deploying New Selectors

   A primary consideration in changing minimal set of headers needed, the selector signature is remembering to
   change it.  It needs
   likely to be a standard part considerably more robust against the handling the
   vagaries of intermediary MTAs.

6.2.  Characteristics of a DKIM signature

   A DKIM signature covers the operational staff
   Methods message body and Procedures for your systems.  If they are separate, both selected header fields.
   The signer computes a hash of the mail team selected header fields and another
   hash of the DNS team will be involved in deploying new
   selectors.

   When deploying body.  The signer then uses a new selector, it needs to be phased in:

   1.  Generate the new public / private key pair and create to
   cryptographically encode this information, along with other signing
   parameters.  Signature information is placed into a new
       selector record with [RFC2822]
   header field of the public key message.

6.3.  The Selector construct

   A signature is associated with a domain name, as specified in it.

   2.  Add the new selector record to your DNS.

   3.  Verify that
   "i=" (or "d=" if "i=" is not present) DKIM-Signature header field
   parameters.  That domain name is the new selector record can be complete identity used to verify
       signatures.

   4.  Turn on signing with for
   making assessments about the new private key.

   5.  Remove signer.  However this name is not
   sufficient for making a DNS query to obtain the old private key from your servers.

   6.  After needed to verify
   the signature.

   A single domain can use multiple signing keys and/or multiple
   signers.  To support this, DKIM identifies a period particular signature as
   a combination of time, remove the old selector from your DNS.

   The time domain name and an unused added field, called the
   "selector", coded into separate DKIM-Signature header field
   parameters.

   NOTE:   The selector should is not intended to be kept in part of the DNS system domain name
      that is
   dependent on the reason it's being changed.  If the private key has
   definitely been exposed, used for making assessments.  Rather, the corresponding selector should be removed
   immediately.  Otherwise, longer periods are allowable.

2.6.1.3.  Subdomain Considerations

   A Domain Name is the basis
      strictly reserved for making differential quality
   assessments about use in administering keys that are
      associated with the domain name.  If the selector becomes part of
      a DKIM-signed message.  It name assessment mechanism, then there is reasonable no remaining mechanism
      for making a
   single organization transition from an old, or compromised, key to have a variety of very different activities,
   which warrant a variety of very different assessments.  A convenient
   way new
      one.

   Signers often need to distinguish among support multiple assessments about their
   organization, such activities is as to sign with different
   domain names.  That is, distinguish one type of message from
   another, or one portion of the organization should sign with sub-domain
   names from another.  To permit
   assessments that are used independent, one method is for different organizational activities.

2.6.1.4.  Third party Signature Delegations

   Allowing third parties to sign email from your domain opens your
   system security an organization
   to include the security of use different sub-domains in the third party's systems.
   At "d=" parameter, such as
   "transaction.example.com" versus "newsletter.example.com", or
   "productA.example.com" versus "productB.example.com".

6.4.  Verification

   After a minimum, you should not allow message has been signed, any agent in the third parties to use message transit
   path can verify the same
   selector and private key as your main mail system.  It is recommended signature, to determine that each third party be given their own private key and selector.
   This limits the exposure signing identity
   took responsibility for any given private key, and minimizes the
   impact if any given private key were exposed.

2.6.2.  Private Key Management

   The permissions of private key files must be carefully managed.  If
   key management hardware support is available, it should be used.
   Auditing software should be used to periodically message.  Message recipients can verify that
   the
   permissions on signature by querying the private key files remain secure.

2.6.3.  Mailing list manager developers

   A mailing list often provides facilities DNS for the signer's domain directly,
   to its administrator retrieve the appropriate public key, and thereby confirm that the
   message was attested to
   manipulate parts by a party in possession of the mail messages that flow through the list.
   The desired goal is that messages flowing through private key
   for the mailing list signing domain.  Typically, verification will be verifiable done by an
   agent in the recipient as being from ADMD of the list, or
   failing that, message recipient.

7.  Service Architecture

   The DKIM service is divided into components that can be performed
   using different, external services, such as being from the individual list members.

   In most cases, for key retrieval.
   However the list and/or its mail host SHOULD add its own basic DKIM signing specification defines an initial set
   of these services, in order to ensure a basic level of
   interoperability.

                           |
                           |- RFC2822 Message
                           V
            +------------------------------------+
            | ORIGINATING OR RELAYING ADMD (MSA) |
            |                                    |
        +..>| Sign Message                       |
        .   +--------------+---------------------+
        .                  |
        .private           |
    +---+---+              |
    |  Key  |              |                    +-----------+
    | Store |          [Internet]               |  Sender   |
    +---+---+              |                    | Practices |
        .public            |                    +-----+-----+
        .                  V                          .
        .   +-----------------------------------+     .
        .   | RELAYING OR DELIVERING ADMD (MDA) |     .
        .   |                                   |     .
        .   | Message Signed?                   |     .
        .   +-------+----------------+----------+     .
        .           |yes             |no              .
        .           V                V                .
        .      +-----------+     +-----------+        .
        +.....>| Verify    | +-->| Check     |<.......+
               | Signature | |   | Practices |<.......+
               +---+-----+-+ |   +---+-------+        .
                   |     |   |       |                .
                   |     +---+       |                .
                   |pass  fail       |                .
                   V                 |          +-----+-----+
               +--------+            |          |  Local    |
      +.......>| Assess |            |          |  Sender   |
      .        | Signer |            |          | Practices |
      .        +---+----+            |          +-----------+
      .  assessment|                 |
      .            +------+   +------+
      .                   |   |
    +-+-----------+       V   V
    | Reputation/ |   +-----------+
    |Accreditation|   | Message   |
    |    Info     |   | Filtering |
    +-----+-------+   | Engine    |
                      +-----------+>

                    Figure 2: DKIM
   signature to list mail.  This could be done in the list management
   software, Service Architecture

   As shown in an outgoing MSA or MTA, or both.  List management
   software often makes modifications to messages that will break
   incoming signatures, such as adding subject tags, adding Figure 2, basic message
   headers or footers, and adding, deleting, or reordering MIME parts.
   By adding its own signature after these modifications, the list
   provides a verifiable, recognizable signature for list recipients.

   In some cases, the modifications made by the mailing list software
   are simple enough that signatures on incoming messages will still be
   verifiable after being remailed by the list.  It processing is still preferable
   that the list sign its mail so that recipients can distinguish divided between mail sent through the list
   MSA and mail sent directly to a list
   member.  In the absence of a list signature, a recipient may still be
   able to recognize and use MDA.

   The MSA  The MSA signs the original signatures of message, using private information from
      the list
   members.

2.7.  Example Uses

   A DKIM signature tells Key Store.

   The MDA  The MDA verifies the signature verifier that the owner of or determines whether a
   particular domain name accepts responsibility for
      signature was required.  Verifying the message.
   Combining this information with signature uses public
      information that allows the history
   of the domain name owner to be assessed may allow processing the
   message, based on the probability that the message is likely to be
   trustworthy, or not, without the need for heuristic content analysis.

2.7.1.  Protection of Internal Mail

   One identity is particularly amenable to easy and accurate
   assessment: The organization's own identity.  Members of an
   organization tend to trust messages that purport to be from within
   that organization.  However Internet Mail does not provide a
   straightforward means of determining whether such mail is, in fact, from within the organization.  DKIM can be Key Store.  If the signature passes,
      reputation information is used to remedy this
   exposure. asses the signer and that
      information is passed to the message filtering system.  If the organization signs all of its mail, then its
   boundary MTAs can look for mail purporting
      signature fails or there is no signature, information about the
      sender's practices is retrieved remotely and/or locally, and that
      information is passed to be from the
   organization but message filtering system.

   Note:  Figure 2 does not contain a verifiable signature.  Such mail
   can be presumed to be spurious.

2.7.2.  Recipient-based Assessments

   Recipients of large volumes of email can internally generate
   reputation data for email senders.  Recipients show the affects on the flow of smaller volumes multiple
      signatures or third-party signatures.

7.1.  Administration and Maintenance

   A number of
   messages tables and services are likely to need used to acquire reputation data from provide external
   information.  Each of these introduces administration and maintenance
   requirements.

   Key Store  DKIM uses public/private (asymmetric) key technology.  The
      signer users a third
   party.  In either case private key and the use of reputation data is intrinsically
   limited validator uses the
      corresponding public key.  The current DKIM signing specification
      provides for querying the Domain Names Service (DNS), to email senders that permit a
      validator to obtain the public key.  The signing organization
      therefore must have established a prior history means of
   sending messages.

   In fact, an email receiving service may be in adding a position key to establish
   bilateral agreements with particular senders, such as business
   partners or trusted bulk sending services.  Although it is not
   practical the DNS, for each recipient to accredit every sender,
      selector/domain-name combination.  Further, the definition
   of core networks of explicit trust can be quite useful.

2.7.2.1.  Third-party Assessments

   For scaling efficiency, it is appealing to have Trusted Third Party
   assessment services, to allow an email sender to obtain signing
      organization needs policies for distributing and revising keys.

   Sender Practices  If a single
   assessment that is message contains a valid signature, then recognized by every email recipient the
      verifier can evaluate the associated domain name's reputation.  If
      a message does not contain a valid signature, that
   recognizes fact could be
      useful, if the Trusted Third Party.

2.7.3.  DKIM Support verifier can discover information about the DKIM-
      related practices of one of the agents purportedly involved with
      the message, such as the domain listed in the Client

   The DKIM specification is expected to be used primarily between
   Boundary MTAs, author's FROM header
      field.  Such information might come from tables developed through
      private agreement or other infrastructure components of from standards-based mechanisms.  As they are
      defined, each domain name owner will need to consider what
      information to publish through the originating mechanism and receiving ADMDs.  However there is nothing in DKIM then will need to
      create and maintain it.

   Reputation/Accreditation  "Reputation/Accreditation" provides
      quality-assessment information that is
   specific to those venues.  In particular, it should be possible to
   support signing associated with a domain
      name, and verifying comes in MUAs.

   However, it is common for components of an ADMD's email
   infrastructure many forms and from many sources.  DKIM does
      not define these services.  It's relevance to do violence them is to provide a message, such as to render
      validated domain name, upon which assessments can be made.

7.2.  Signing

   Signing can be performed by a DKIM
   signature invalid.  Hence, users component of MUAs the ADMD that support DKIM signing creates the
   message, and/or verifying need a basis for knowing that their associated email
   infrastructure will not break a signature.

   DKIM requires that all verifiers treat messages with signatures that
   do not verify as if they are unsigned.  If verification in within any ADMD, along the client
   is to relay path.  The signer
   uses the appropriate private key.

7.3.  Verifying

   Verification can be acceptable to users, it is also essential performed by any functional component along the
   relay and delivery path.  Verifiers retrieve the public key based
   upon the parameters stored in the message.

7.4.  Unverified or Unsigned Mail

   Note that successful
   verification of a failed signature not result in a less than satisfactory
   user experience compared to leaving causes the message unsigned.

2.7.4.  Per user signatures

   Although DKIM's use of domain names is optimized for a scope of
   organization-level signing, it is possible to administer sub-domains
   and/or selectors be treated in a way the
   same manner as one that supports per-user signing.

   NOTE:   As stated earlier, it is important to distinguish between unsigned.  Messages lacking a valid
   originator signature (a signature associated with the
      use of selectors for differential administration originator of keys, versus
   the use of sub-domains for differential reputations.

   As message as opposed to a constraint on an authorized DKIM signing agent, their signature associated
   key record can specify restrictions on the email addresses permitted
   to be signed with that domain and key.  A typical intent of this
   feature is to allow an
   intermediary) prompt a company to delegate the signing authority query for
   bulk marketing communications without any published "sender practices"
   information, as an aid in determining whether the risk of effectively
   delegating sender information
   has been used without authorization.

7.5.  Evaluating

   The Figure shows the authority to sign messages purporting verified identity as being used to come from the
   domain-owning organization's CEO.

   NOTE:   Any scheme that involves maintenance assess an
   associated reputation, but it could be applied for other tasks, such
   as management tracking of a significant number mail.  A popular use of public keys reputation
   information is likely to require infrastructure enhancements, as input to support that management.  For example, a system in which the
      end user is required filtering engine that decides whether to generate
   deliver -- and possibly whether to specially mark -- a public key pair message.
   Filtering engines have become complex and transmit it sophisticated.  Their
   details are outside of DKIM's scope, other than the expectation that
   DKIM-related information is added to the DNS administrator out varied soup of band rules used by
   the engines.  The rules can cover signed messages and can deal with
   unsigned messages from a domain, if the domain has published
   information about is not likely to meet
      acceptance criteria for either usability or security.

3. practices

8.  Security Considerations

   TBD

9.  IANA Considerations

   TBD

10.  Acknowledgements

   TBD

4.

11.  Informative References

   [I-D.ietf-openpgp-rfc2440bis]
              Callas, J., "OpenPGP Message Format",
              draft-ietf-openpgp-rfc2440bis-22 (work in progress),
              April 2007.

   [I-D.kucherawy-sender-auth-header]
              Kucherawy, M., "Message Header Field for Indicating Sender
              Message Authentication Status",
              draft-kucherawy-sender-auth-header-04
              draft-kucherawy-sender-auth-header-09 (work in progress),
              February
              November 2007.

   [RFC0989]  Linn, J. and IAB Privacy Task Force, "Privacy enhancement
              for Internet electronic mail: Part I: Message encipherment
              and authentication procedures", RFC 989, February 1987.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1848]  Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME
              Object Security Services", RFC 1848, October 1995.

   [RFC1991]  Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
              Exchange Formats", RFC 1991, August 1996.

   [RFC2440]  Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
              "OpenPGP Message Format", RFC 2440, November 1998.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

   [RFC3156]  Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
              "MIME Security with OpenPGP", RFC 3156, August 2001.

   [RFC3164]  Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
              August 2001.

   [RFC3851]  Ramsdell, B., "Secure/Multipurpose Internet Mail
              Extensions (S/MIME) Version 3.1 Message Specification",
              RFC 3851, July 2004.

   [RFC4686]  Fenton, J., "Analysis of Threats Motivating DomainKeys
              Identified Mail (DKIM)", RFC 4686, September 2006.

   [RFC4870]  Delany, M., "Domain-Based Email Authentication Using
              Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
              May 2007.

   [RFC4871]  Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
              J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
              Signatures", RFC 4871, May 2007.

Authors' Addresses

   Tony Hansen
   AT&T Laboratories
   200 Laurel Ave.
   Middletown, NJ  07748
   USA

   Email: tony+dkimov@maillennium.att.com

   Dave Crocker
   Brandenburg InternetWorking
   675 Spruce Dr.
   Sunnyvale, CA  94086
   USA

   Email: dcrocker@bbiw.net

   Phillip Hallam-Baker
   VeriSign Inc.

   Email: pbaker@verisign.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).