[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12                        
Internet Engineering Task Force                           T. Hansen, Ed.
Internet-Draft                                         AT&T Laboratories
Expires: December 20, 2006                                    D. Crocker
                                             Brandenburg InternetWorking
                                                         P. Hallam-Baker
                                                           VeriSign Inc.
                                                           June 18, 2006

                  DomainKeys Identified Mail Overview

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on December 20, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   DomainKeys Identified Mail DKIM [I-D.ietf-dkim-base] defines a
   domain-level authentication framework for email using public-key
   cryptography and key server technology to permit verification of the
   source and contents of messages by either Mail Transfer Agents (MTAs)
   or Mail User Agents (MUAs).  The ultimate goal of this framework is

Hansen, et al.          Expires December 20, 2006               [Page 1]

Internet-Draft                DKIM Overview                    June 2006

   to permit a signing domain to assert responsibility for a message,
   thus proving and protecting message sender identity and the integrity
   of the messages they convey while retaining the functionality of
   Internet email as it is known today.  Proof and protection of email
   identity, including repudiation and non-repudiation, may assist in
   the global control of "spam" and "phishing".

   This document provides an overview of DomainKeys Identified Mail and
   how it can fit into overall messaging systems, how it relates to
   other IETF message signature technologies, implementation and
   migration considerations, and outlines potential DKIM applications
   and future extensions.


   This document is being discussed on the DKIM mailing list,

Hansen, et al.          Expires December 20, 2006               [Page 2]

Internet-Draft                DKIM Overview                    June 2006

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  About This Document  . . . . . . . . . . . . . . . . . . .  5
     1.2.  A Quick Overview of DKIM . . . . . . . . . . . . . . . . .  5
       1.2.1.  Axiom: Ubiquitous Authentication is Good . . . . . . .  5
       1.2.2.  What is the purpose of DKIM? . . . . . . . . . . . . .  6
       1.2.3.  What does DKIM do? . . . . . . . . . . . . . . . . . .  7
       1.2.4.  Who validates the signature? . . . . . . . . . . . . .  7
       1.2.5.  What does DKIM *not* do? . . . . . . . . . . . . . . .  7
     1.3.  Outline Potential DKIM Applications  . . . . . . . . . . .  8
   2.  DKIM Within Existing Internet Email  . . . . . . . . . . . . .  8
     2.1.  Where to Place DKIM Functions  . . . . . . . . . . . . . .  8
     2.2.  Impact on Email Activities . . . . . . . . . . . . . . . .  8
       2.2.1.  Resources  . . . . . . . . . . . . . . . . . . . . . .  8
       2.2.2.  Operations . . . . . . . . . . . . . . . . . . . . . .  9
       2.2.3.  Users  . . . . . . . . . . . . . . . . . . . . . . . .  9
     2.3.  Migrating from DomainKeys  . . . . . . . . . . . . . . . .  9
       2.3.1.  Signing  . . . . . . . . . . . . . . . . . . . . . . .  9
       2.3.2.  Verifying  . . . . . . . . . . . . . . . . . . . . . . 10
     2.4.  { Misc Text -- Should go elsewhere, if used at all } . . . 10
   3.  Relationship to previous Message Signature Technologies  . . . 11
     3.1.  Transparent Signature  . . . . . . . . . . . . . . . . . . 11
     3.2.  Treat verification failure as if unsigned. . . . . . . . . 12
     3.3.  Legacy Client Semantics  . . . . . . . . . . . . . . . . . 13
     3.4.  Key Centric PKI  . . . . . . . . . . . . . . . . . . . . . 13
     3.5.  Domain Level Assurance . . . . . . . . . . . . . . . . . . 15
     3.6.  Security Policy  . . . . . . . . . . . . . . . . . . . . . 15
   4.  Implementation Considerations  . . . . . . . . . . . . . . . . 16
     4.1.  Development  . . . . . . . . . . . . . . . . . . . . . . . 16
       4.1.1.  Signer . . . . . . . . . . . . . . . . . . . . . . . . 16
       4.1.2.  Validator  . . . . . . . . . . . . . . . . . . . . . . 16
       4.1.3.  Outbound mail user agent . . . . . . . . . . . . . . . 16
       4.1.4.  Outbound mail transport agent  . . . . . . . . . . . . 16
       4.1.5.  DNS Server . . . . . . . . . . . . . . . . . . . . . . 16
       4.1.6.  Mailing list manager . . . . . . . . . . . . . . . . . 16
       4.1.7.  Inbound mail transport agent . . . . . . . . . . . . . 16
       4.1.8.  Inbound mail user agent  . . . . . . . . . . . . . . . 17
       4.1.9.  Accreditation service  . . . . . . . . . . . . . . . . 17
     4.2.  Deployment . . . . . . . . . . . . . . . . . . . . . . . . 17
       4.2.1.  Signing  . . . . . . . . . . . . . . . . . . . . . . . 17
       4.2.2.  Verifying  . . . . . . . . . . . . . . . . . . . . . . 17
     4.3.  Operations . . . . . . . . . . . . . . . . . . . . . . . . 17
       4.3.1.  DNS Signature Record Deployment Considerations . . . . 17
       4.3.2.  Thoughts on Expiring Signatures  . . . . . . . . . . . 17
       4.3.3.  DNS Policy Record Deployment Considerations  . . . . . 18
       4.3.4.  Subdomain Considerations . . . . . . . . . . . . . . . 18
       4.3.5.  Third party Signature Delegations  . . . . . . . . . . 18

Hansen, et al.          Expires December 20, 2006               [Page 3]

Internet-Draft                DKIM Overview                    June 2006

   5.  Outline Future Extensions  . . . . . . . . . . . . . . . . . . 18
     5.1.  Introducing a new signing algorithm  . . . . . . . . . . . 19
     5.2.  Possible future signature algorithm choices  . . . . . . . 19
     5.3.  Transition strategy  . . . . . . . . . . . . . . . . . . . 20
       5.3.1.  Signer transition strategy . . . . . . . . . . . . . . 20
       5.3.2.  Verifier transition strategy . . . . . . . . . . . . . 21
     5.4.  Linkage to Other PKIs  . . . . . . . . . . . . . . . . . . 21
     5.5.  Trusted Third Party Assertions . . . . . . . . . . . . . . 22
     5.6.  Linkage to X.509 Certificates  . . . . . . . . . . . . . . 23
     5.7.  XKMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     5.8.  Verification in the Client . . . . . . . . . . . . . . . . 24
     5.9.  Per user signature . . . . . . . . . . . . . . . . . . . . 25
     5.10. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 25
     5.11. Reuse of Key Record  . . . . . . . . . . . . . . . . . . . 26
     5.12. Use of Policy Record . . . . . . . . . . . . . . . . . . . 26
   6.  What Needs To Be Moved Here From the Base Doc? . . . . . . . . 27
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 27
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
   Intellectual Property and Copyright Statements . . . . . . . . . . 30

Hansen, et al.          Expires December 20, 2006               [Page 4]

Internet-Draft                DKIM Overview                    June 2006

1.  Introduction

1.1.  About This Document

   This document provides an overview of DomainKeys Identified Mail
   (DKIM).  It provides information for: those who are adopting DKIM;
   those who are developing DKIMd;, those who are deploying DKIM; and
   those who are considering extending DKIM, either into other areas or
   to provide additional features.

   This document does not provide information on threats to DKIM or
   email, or details on the implementation.  Such information can be
   found in other RFC documents.[I-D.ietf-dkim-base] [I-D.ietf-dkim-
   threats] Nor does this document describe how to solve the world's
   problems with spam, phish, virii, worms, joe jobs, etc.

   [ NOTE: a number of sections in this document are just placeholders
   for now ]

1.2.  A Quick Overview of DKIM

1.2.1.  Axiom: Ubiquitous Authentication is Good

   DKIM builds on previous work in the form of Domain Keys, Identified
   Internet Mail, Authenticated Sender, Meta-Mail, etc.  The starting
   point for all of these technologies, and now DKIM, is the belief that
   authenticating email is a good thing to do in and of itself.  It has
   been pointed out that it is unlikely that RFC 822 [RFC0822] would
   pass today without some form of strong authentication mechanism.
   DKIM provides such a strong authentication mechanism.

   The ultimate goal of DKIM is to achieve a situation where email
   authentication is ubiquitous and the unsigned email becomes the
   exception the rule, as is the case today.  Only when the majority of
   Internet email is authenticated is it possible to make interesting
   conclusions about the lack of authentication.

   It follows then that a new message signature scheme is required to
   meet the goal of ubiquitous authentication.  In each of the above-
   mentioned proposals, several design elements are shared:

      The signature is carried in the message header and does not affect
      the message body.

      The signature may include certain headers.

      There is a policy mechanism, either explicit or implicit, that
      tells receivers when to expect a signature.

Hansen, et al.          Expires December 20, 2006               [Page 5]

Internet-Draft                DKIM Overview                    June 2006

      Keys are self-created (it is not necessary to buy a certificate).

      Keys are stored in the DNS (it is not necessary to deploy a
      separate key server).

   The remarkable similarity of these architectural proposals strongly
   suggests that this architecture should be the basis for unbiquitous
   authentication.  DKIM was produced by merging the two previous
   proposals of DomainKeys and Identified Internet Mail.  Significant
   enhancements were then made from that base.

   The approach taken by DKIM differs from previous approaches to
   message signing in that:

      the message signature is written as a message header field so that
      neither human recipients nor existing MUA (Mail User Agent)
      software are confused by signature-related content appearing in
      the message body,

      there is no dependency on public and private key pairs being
      issued by well-known, trusted certificate authorities,

      there is no dependency on the deployment of any new Internet
      protocols or services for public key distribution or revocation,

      it makes no attempt to include encryption as part of the

1.2.2.  What is the purpose of DKIM?

   DKIM lets an organization take responsibility for a message.  The
   organization taking responsibility is a handler of the message,
   either as its originator or as an intermediary.  Their reputation 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.  This means that
   their reputation is at stake.

   By design, DKIM purposely:

      is compatible with the existing email infrastructure and
      transparent to the fullest extent possible

      requires minimal new infrastructure

      can be implemented independently of clients in order to reduce
      deployment time

Hansen, et al.          Expires December 20, 2006               [Page 6]

Internet-Draft                DKIM Overview                    June 2006

      does not require the use of trusted third parties (e.g.,
      certificate authoritys) which might impose significant costs or
      introduce delays to deployment

      can be deployed incrementally

      allows delegation of signing to third parties

      is not intended be used for archival purposes

   DKIM authentication provides one link in a chain of responsibility,
   hopefully leading to better accountability by the senders.

1.2.3.  What does DKIM do?

   DKIM defines a mechanism by which email messages can be
   cryptographically signed, permitting a signing domain to claim
   responsibility for the introduction of a message into the mail
   stream.  The responsible organization adds a digital signature to the
   message, associating it with a domain name of that organization.
   Typically, signing will be done by an service agent within the
   authority of the message originator's Administrative Management
   Domain (ADMD).  (Signing might be performed by any of the functional
   components in that environment, including a Mail User Agent (MUA), a
   Mail Submission Agent (MSA), or an Internet Boundary MTA.  DKIM also
   permits signing to be performed by authorized third-parties.)

1.2.4.  Who validates the signature?

   After a message has been signed, any agent in the message transit
   path can choose to validate the signature.  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, validation will be done by an
   agent in the ADMD of the message recipient.  Again, this may be done
   by any functional component within that environment.  (Notably this
   means that the signature can be used by the recipient ADMD's
   filtering software, rather than requiring the recipient end-user to
   make an assessment.)

1.2.5.  What does DKIM *not* do?

   DKIM does not:

   o  offer any assertions about the behaviors of the identity doing the

Hansen, et al.          Expires December 20, 2006               [Page 7]

Internet-Draft                DKIM Overview                    June 2006

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

   o  provide protection after message delivery.

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

1.3.  Outline Potential DKIM Applications


2.  DKIM Within Existing Internet Email

   Email service architecture review.

   AdMD to AdMD, not MTA to MTA.  (AdMD not equal Domain Name.)

2.1.  Where to Place DKIM Functions

   DKIM may be run within any component of an AdMD, such as:

      Outbound:  MSA or boundary MTA.

      Inbound:  Boundary MTA or MDA.

   {explain basis tradeoffs/reasons for choices: s/w availability, user-
   vs-ops, admin control/ease...}

2.2.  Impact on Email Activities

2.2.1.  Resources

   Although the cryptographic authentication are considered to be
   computationally expensive, the real impact of a mechanism, like DKIM,
   is remarkably small.  Direct impact on CPU-load has been measured to
   be 10-15%.  Usually, email is i/o-intensive, with unused
   computational capacity.  So, it is likely that no new hardware will
   be required.

Hansen, et al.          Expires December 20, 2006               [Page 8]

Internet-Draft                DKIM Overview                    June 2006

2.2.2.  Operations

   Administrative cost to deploy, versus expected reduction in the cost
   of administration for problem email.

   Challenge of mobile users.  Server-resident folders -- web or imap --
   no problem.  Laptop-resident folders, requires remote MSA access or
   per-user keying and mobile-author awareness.

   Key creation and replacement.  Update DNS and signing component

2.2.3.  Users

   Challenge of mobile users.  Server-resident folders -- web or imap --
   no problem.  Laptop-resident folders, requires remote MSA access or
   per-user keying and mobile-author awareness.

   Challenge of mailing lists.  Different list styles warrant different
   signature policies.

   Can be hidden from end-user; used by filter engine.  Method and
   benefits for displaying to users unknown.

2.3.  Migrating from DomainKeys

2.3.1.  Signing  DNS Records

   DKIM is upward compatible with existing DomainKeys (DK) DNS records,
   so that a DKIM module does not automatically require additional DNS
   administration!  DKIM has enhanced the DK DNS key record, to permit
   the addition of several parameters.  Signing Module

   DKIM uses a different RFC2822 [RFC2822] header field for storing the
   signature, in order to distinguish it from DK.

   DKIM includes language to make it clear which particular header field
   is signed, if there is more than one header field of a given name in
   the message.

   DKIM allows some values that were scalars in DomainKeys to be colon-
   separated arrays.  For example, the list of query methods used to
   find a key and the "t=" tags (originally testing, now flags).

   DKIM permits copying the original version of headers fields and their

Hansen, et al.          Expires December 20, 2006               [Page 9]

Internet-Draft                DKIM Overview                    June 2006

   values, to aid in diagnosing signatures that do not survive transit.

   DKIM has the ability to limit keys to hash algorithms specified in a
   list, in the DNS record.

   DKIM allows body length limits, to permit signatures, to survive
   transit through some intermediaries, such as some mailing list agents
   that add text to the end of the message.  Boundary MTA

   Enforce signature policies and practises

2.3.2.  Verifying  DNS Client  Verifying module

   See "Signing Module".  Boundary MTA

   Strip "local" signatures that are not local?

2.4.  { Misc Text -- Should go elsewhere, if used at all }

   DKIM permits the signing identity to be different from the identities
   used for the author or the initial posting agent.  This is essential,
   for example, to enable support of signing by authorized third-
   parties, and to permit signatures by email providers who are
   otherwise independent of the domain name of the message author.

   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.  This is an improvement because it requires the signer to use
   the more conservative (likely to verify correctly) mechanism and
   makes it considerably more robust against the handling of
   intermediary MTAs.

   DKIM self-signs the DKIM-Signature header field, to protect against
   its being modified.

   In order to survive the vagaries of different email transfer systems,

Hansen, et al.          Expires December 20, 2006              [Page 10]

Internet-Draft                DKIM Overview                    June 2006

   mechanisms like DKIM must evaluate the message data in some canonical
   form, such as treating a string of spaces as tabs as if they were a
   single space.  DKIM has added the "relaxed" canonicalization in place
   of "nofws".

3.  Relationship to previous Message Signature Technologies

   DKIM is the fifth IETF proposal for an email signature scheme.  The
   first RFC describing Privacy Enhanced Mail (PEM) was published in
   1987 [RFC0989].  The PEM scheme went through a number of revisions
   and eventually transformed into MIME Object Security Services in 1995

   Neither PEM nor MOSS ever achieved significant deployment.  PEM
   relied on the prior deployment of an extensive PKI predicated on a
   rigid hierarchy of Certificate Authorities.  By the time it was
   understood that this infrastructure assumption was unrealistic the
   opportunity to deploy PEM had closed.

   Pretty Good Privacy (PGP) was developed by Phil Zimmerman and
   released in 1991 and quickly established a significant support base
   within the security community.  This support base was driven by two
   principal factors: superior ease of deployment and an aggressive
   marketing campaign assisted by the U.S. government.  A working group
   was formed within the IETF to continue development of the PGP
   protocol as OpenPGP beginning with publication of the original
   protocol as an informational RFC in 1996 [RFC1991].

   At the same time RSA Security, the holder of the patent rights to the
   principle public key cryptography algorithm independently developed
   Secure MIME (S/MIME) which employed the recently developed MIME
   format to transport a PKCS #7 data object.  S/MIME was particularly
   attractive for software developers who had already implemented SSL as
   much of the code required to support could be reused.

   Development of S/MIME and OpenPGP has continued in the IETF since.
   While both have achieved a significant user base neither has achieved
   ubiquity.  In particular it is notable that only a small percentage
   of messages on the IETF mailing lists concerned with security are

3.1.  Transparent Signature

   The core goals of DKIM require that use of message signatures becomes
   ubiquitous.  For this to be possible it must be possible to apply a
   signature to any message in any circumstance with a negligible chance
   of causing a negative user experience for any recipient regardless of

Hansen, et al.          Expires December 20, 2006              [Page 11]

Internet-Draft                DKIM Overview                    June 2006

   the legacy email client used.

   Experiences from S/MIME and PGP deployment strongly indicate that
   this usability goal can only be met if the addition of the signature
   leaves the message body unchanged.

   S/MIME and PGP are both designed to achieve the highest level of
   security possible.  The sender of a message is assured that the
   confidentiality and/or integrity of the message are protected from
   the originating end point machine to the destination end point.

   Achieving this level of security naturally places requirements on
   both the sender and the receiver.  Support for both signature and
   encryption causes a subtle but important architectural assumption to
   be introduced.  Although signature and encryption are complimentary
   from a cryptographic point of view their effect is entirely different
   from a messaging protocol point of view.  A digital signature is
   meta-data providing information about the message contents.
   Encryption is a transformation of the message content (and possibly
   related meta-data).

   The recipient of an encrypted email message must as a matter of
   course have a specially adapted email client capable of decrypting
   the message.  Adding a signature to the message does not in principle
   create a requirement for the recipient to have a specially adapted
   client provided the signature is added in a manner that is ignored by
   legacy clients.

   In the case of an S/MIME signature the recipient is at a minimum
   expected to have a client capable of decoding the MIME multipart/
   security format.  In practice this means that the recipient must
   support S/MIME.  OpenPGP allows the use of a signature encapsulation
   that is not MIME based.  This has the advantage that the message can
   be read using a standard email client.  The disadvantage with this
   approach is that the application of the signature is visible to the
   user and thus intrusive.

3.2.  Treat verification failure as if unsigned.

   PGP and S/MIME were both designed to meet a high standard of
   cryptographic excellence.  At the time the protocols were designed it
   was generally considered that the correct thing for an application to
   do in the case of a signature verification failure was to warn the
   user that the message was unsigned.  In a small number of cases the
   application went even further 'warning' the user whenever a signed
   message was received.

   This type of user experience has since been severely deprecated.  A

Hansen, et al.          Expires December 20, 2006              [Page 12]

Internet-Draft                DKIM Overview                    June 2006

   user who is constantly bombarded with warning messages is much less
   likely to respond appropriately when an important warning message is

   While modern messaging infrastructure is considerably friendlier to
   the use of digital signatures than in the past even a residual
   failure rate of 1% results in unacceptably high support costs when
   signatures are used ubiquitously.

   It is now generally accepted that the correct semantics for an email
   signature verifier to adopt are to treat messages with signatures
   that fail as if they are unsigned.

   It is highly unlikely that an attacker is going to add a digital
   signature to a message unless doing so causes the message to be
   treated more favorably than an unsigned one.  Any messages that carry
   signatures that fail verification are thus much more likely to be a
   genuine message that has been damaged in transit than an attempted
   forgery.  It makes no sense to warn the recipient unless it is known
   that the sender always signs email messages and that there is a high
   probability that a forgery would be attempted.

3.3.  Legacy Client Semantics

   The deployed base of S/MIME is both a benefit and a burden.  While
   the S/MIME protocol is in principle capable of extension to support
   many of the features of DKIM, the same is not true of the deployed
   S/MIME base.

   While the S/MIME protocol can in principle support semantics such as
   domain level signatures or make use of keys stored in the DNS the
   legacy deployed base does not.  The behavior of legacy clients
   receiving an S/MIME message dependent on the novel semantics is
   likely to result in a negative user experience in a significant
   number of cases.

3.4.  Key Centric PKI

   Unlike all four previous IETF email security initiatives, DKIM
   employs a key centric, directory based PKI as opposed to a
   certificate based PKI in the style of Kohnfelder (X.509) or Zimmerman
   (web of trust).

   While message syntax and PKI are orthogonal in principle,
   implementation practice means that most S/MIME clients only support
   use of keys contained in X.509/PKIX digital certificates.

   Although PGP is sometimes held up as an alternative to a certificate

Hansen, et al.          Expires December 20, 2006              [Page 13]

Internet-Draft                DKIM Overview                    June 2006

   based PKI a PGP key signing is in essence a digital certificate by
   another name.  There has since been considerable conversion as X.509
   has adopted the web of trust principle under the term cross-
   certification.  The chief distinction between the PGP and PKIX models
   is that in the PGP model every user is also (potentially) a trust
   provider.  In PKIX trust providers are distinct from end-entities.

   The Kohnfelder architecture was originally designed to allow use of
   public key cryptography before the ubiquitous availability of
   networking.  A particular benefit of the Kohnfelder architecture is
   that Alice can send an encrypted message to Bob when the only
   transport available is sending floppy disks through the postal
   system.  Another benefit of the Kohnfelder architecture is that a
   signed message supported by a digital certificate is self supporting
   and may be verified years after the fact provided only that the CA
   signing key does not become compromised.

   The principle weakness in PKIs based on the Kohnfelder architecture
   is the difficulty of locating the correct digital key in the absence
   of a directory infrastructure.  This led Brian LaMacchia, then at MIT
   to develop the MIT PGP key server, in effect returning to the
   original public key directory model proposed by Whitt Diffe and Marty

   XML Key Management Service (XKMS) realizes the key centric PKI model
   as a SOAP based Web Service.  In the XKMS model the PKI client makes
   a request of the form 'provide me with the signing key that Alice
   uses with the PGP protocol'.

   Although DKIM follows the same architectural model as XKMS, DNS is
   used as the transport layer in place of SOAP over HTTP.

   The use of DNS significantly reduces the infrastructure requirements
   for DKIM as existing DNS servers are used for key distribution.  This
   approach also has significant performance advantages as DNS is layers
   on UDP and key retrieval is typically achieved in a single round
   trip.  XKMS requires a TCP session to be established and the request
   and response messages are significantly larger.

   The principle disadvantage of using DNS over XKMS is that the DNS is
   a network administration resource designed to answer questions about
   current network configuration.  While it is quite possible to re-use
   the DNS infrastructure to support queries about past and even future
   network configurations this is not the core objective of the
   infrastructure.  The DNS is thus unsuited to supporting any use of
   digital signatures in which long term archival is desirable or the
   possibility of repudiation is undesirable.

Hansen, et al.          Expires December 20, 2006              [Page 14]

Internet-Draft                DKIM Overview                    June 2006

3.5.  Domain Level Assurance

   As previously mentioned PGP and S/MIME were designed in the heyday of
   the security end-to-end principle.  It has since been realized that
   the end points with respect to trust are not the same as the end
   points with respect to the communication protocol.

   When Alice sends a personal message to Bob it is Alice the person,
   not the machine Alice happens to be using that is the true trust end
   point.  When Alice sends a piece of business correspondence to Bob it
   is her employer.

   The objective of DKIM is to allow parties to accept responsibility
   for messages by signing them.  While accepting responsibility at the
   personal level may be desirable in some circumstances the Internet
   now has a billion users.  Attempting to achieve accountability in a
   population of a billion users is impractical, particularly when the
   owner of the domain example.com has the ability to create a
   practically unlimited number of accounts within that domain at will.

   The logical unit of accountability for DKIM is therefore the DNS
   domain name to which the signing key record is bound and not the
   individual email user.

3.6.  Security Policy

   The innovation in DKIM that has no precedent in the previous email
   security standards is the publication of a security policy.  The
   purpose of DKIM is to allow a party to accept responsibility for an
   email message by signing it.  A message with a signature is treated
   as if it is unsigned.  For a recipient to interpret an unsigned
   message it is necessary to know whether it should expect a message
   from that source to be signed and if so the signature characteristics
   to expect.

   The introduction of security policy allows unsigned messages and
   messages that fail signature validation to be subjected to a higher
   level of anti-spam filtering or rejected out of hand in circumstances
   where the owner of the purported originating domain suggests.  For
   example a bank concerned at the possibility of phishing attack might
   publish a policy stating that all legitimate messages from the domain
   are signed.

   While the Sender-ID/SPF security policy format allows application to
   existing formats including PGP and S/MIME the advantages to
   developing the protocol and security policy in tandem are
   considerable.  It is not practical to expect to be able to write a
   useful sender signing policy for S/MIME or PGP within the constraints

Hansen, et al.          Expires December 20, 2006              [Page 15]

Internet-Draft                DKIM Overview                    June 2006

   of the 512 byte response message size imposed on the legacy DNS.

4.  Implementation Considerations

4.1.  Development

   What software has to change, to use DKIM?

4.1.1.  Signer

   The signer needs to add code in the appropriate agent, to perform
   signing, and they need to modify their DNS administrative tools to
   permit creation of DKIM key records.

4.1.2.  Validator

   A validator needs to add code to the appropriate agent and then feed
   the result into the portion of their system needing it, such as a
   filtering engine.

   The mere existence of a valid signature does not imply that the mail
   is acceptable, such as for delivery.  Acceptability requires an
   assessment phase.  Hence the result of signature validation must be
   fed into a vetting mechanism that is part of the validator's filter.

4.1.3.  Outbound mail user agent


4.1.4.  Outbound mail transport agent


4.1.5.  DNS Server


4.1.6.  Mailing list manager


4.1.7.  Inbound mail transport agent


Hansen, et al.          Expires December 20, 2006              [Page 16]

Internet-Draft                DKIM Overview                    June 2006

4.1.8.  Inbound mail user agent


4.1.9.  Accreditation service


4.2.  Deployment

4.2.1.  Signing  DNS Records

   add sig key info  Signing Module

   Delete old signs with same key; add new sig  Boundary MTA

   Enforce signature policies and practises

4.2.2.  Verifying  DNS Client

   Ensure able to obtain DKIM key sig records  Verifying module

   Validate sig; channel info to filtering engine.  Maybe provide user-
   visible info.  Boundary MTA

   Strip "local" signatures that are not local?

4.3.  Operations

4.3.1.  DNS Signature Record Deployment Considerations


4.3.2.  Thoughts on Expiring Signatures


Hansen, et al.          Expires December 20, 2006              [Page 17]

Internet-Draft                DKIM Overview                    June 2006

4.3.3.  DNS Policy Record Deployment Considerations


4.3.4.  Subdomain Considerations


4.3.5.  Third party Signature Delegations


5.  Outline Future Extensions

   The design of DKIM is unapologetically focused on overcoming the need
   for immediate deployment and achieving ubiquitous use in the near
   future.  As such the original design discussions have generally taken
   the approach 'if in doubt leave it out'.

   The need to exclude consideration of these features in the near term
   is in no way intended to preclude their development at a later date.
   Nor is the lack of a specification describing the use of DKIM with a
   different PKI infrastructure intended to indicate an intention to
   develop similar capabilities within the DKIM framework at a future

   DKIM is an example of 'Design for Deployment'.  The need to support
   rapid deployment is the overriding priority.  It has traditionally
   been asserted that deployment of a flawed cryptographic protocol is
   an almost unacceptable risk, that bad security is worse than no
   security.  Experience demonstrates otherwise.  Informing users that
   email is insecure does not cause them to modify their behavior to
   avoid dependence thereupon.  Deployment of flawed cryptographic
   security systems such as SSL and WEP has been rectified far more
   quickly than deployment of protocols such as IPSEC or DNSSEC where
   caution has prevailed.

   One possible future for DKIM is that it becomes the starting point
   for a new cryptographic infrastructure that eventually replaces
   legacy systems including S/MIME and PGP.  While this future is
   certainly preferable to never achieving ubiquitous deployment of
   strong cryptographic security in the Internet it would certainly take
   a long time to re-invent this particular wheel.  Moreover the
   deployment of the proposed DKIM enhancements would face political
   opposition from the adherents to existing formats to be rendered
   historical.  A likely outcome of such a strategy is that the existing
   two way standards stalemate between S/MIME and PGP would become a

Hansen, et al.          Expires December 20, 2006              [Page 18]

Internet-Draft                DKIM Overview                    June 2006

   three way stalemate.

   Another possible future is that DKIM provides the 'bootstrap' that
   enables ubiquitous use of legacy infrastructure including the
   deployed base of PGP and S/MIME capable email clients and the
   existing business infrastructure of commercial Certificate
   Authorities.  Such a strategy would make use of DKIM in conjunction
   with existing PKI standards such as PKIX and XKMS and leverage
   features of PGP and S/MIME where appropriate.

5.1.  Introducing a new signing algorithm

   Regardless of whether extension of the DKIM feature set is desirable
   the need to replace the signature algorithm is practically a
   certainty.  The RSA signature algorithm at best provides equivalent
   security to an 80 bit symmetric cipher when used with a 1024 bit key
   [cite].  Extending the key size to 2048 bits improves the cipher
   strength to only 112 bit equivalence.  Achieving 128 bit security
   requires a minimum of 3072 bits.  Achieving equivalent cipher
   strength to a 192 bit symmetric algorithm requires a prohibitive key

   The choice of cryptographic algorithm affects the DKIM algorithm in
   two important ways.  First there is the difficulty of storing keys in
   the DNS.  Secondly there is the problem of handling larger

   The default DNS response packet limit of 512 bytes places an
   effective upper bound of 4096 bits on a DKIM key.  In practice the
   need for packaging, meta-data and the desirability of using DNSSEC to
   sign the record reduces the upper bound to no more than 2048 bits.

   The size of the DKIM signature itself is a weaker constraint.  Even
   so, while 1024 and even 2048 bit signatures are likely to be
   acceptable in most implementations larger signature sizes may become
   prohibitive, particularly as the signature must be Base 64 encoded.

5.2.  Possible future signature algorithm choices

   ECC cryptography offers a means of implementing public key
   cryptography using a key size and signature size that are each only
   twice the size of the equivalent symmetric key algorithm.

   While ECC offers clear technical advantages over algorithms based on
   the difficulty on solving the discrete log problem in a finite field
   it is not possible at this point to be confident that a means of
   applying ECC that is consistent with the position on intellectual
   property adopted by the DKIM working group has been found.

Hansen, et al.          Expires December 20, 2006              [Page 19]

Internet-Draft                DKIM Overview                    June 2006

   The DSA signature algorithm based on the discrete log problem faces
   the same key size limitations as RSA.  Importantly for the design of
   DKIM and DNSSEC however the signature size is much smaller, the same
   size as for ECC algorithms.

   It is likely that DSA would have received greater attention during
   the design of DSA if key sizes greater than 512 bits and use of hash
   functions stronger than SHA-1 had been supported at the time.  In
   March 2006 a proposed revision of the DSA signature algorithm
   answered these objections permitting larger key sizes and specifying
   use of stronger hash functions including SHA-256 and SHA 512.  While
   the advantages offered by DSA are not sufficient to warrant an
   immediate transition to the new algorithm at this late stage it is
   highly probably that the algorithm will be employed by DNSSEC when
   finally deployed.

5.3.  Transition strategy

   Deployment of a new signature algorithm without a 'flag day' requires
   a transition strategy such that signers and verifiers can phase in
   support for the new algorithm independently and if necessary phase
   out support for the old algorithm independently.

   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 to be advertised, thus preventing a downgrade

5.3.1.  Signer transition strategy

   Let the old signing algorithm be A, the new signing algorithm be B.
   The sequence of events by which a Signer may introduce a new signing
   algorithm without disruption of service to legacy verifiers is as

   1.  Signer signs with algorithm A

       A.  Signer advertises that it signs with algorithm A

   2.  Signer signs messages twice, first with algorithm A and algorithm

       A.  The signer tests new signing configuration

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

Hansen, et al.          Expires December 20, 2006              [Page 20]

Internet-Draft                DKIM Overview                    June 2006

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

   4.  Signer determines that support for algorithm A it to be withdrawn

       A.  Signer removes advertisement for Algorithm A

       B.  Signer waits for cached copies of earlier signature policy to

       C.  Signer stops signing with Algorithm A

5.3.2.  Verifier transition strategy

   The actions of the verifier are independent of the signer's actions
   and do not need to be performed in a particular sequence.  The
   verifier may make a decision to cease accepting algorithm A without
   first deploying support for algorithm B. Similarly a verifier may be
   upgraded to support algorithm B without requiring algorithm B to be
   withdrawn.  The decisions of the verifier must make are therefore:

   o  The verifier MAY change the degree of confidence associated with
      any signature at any time, including determining that a given
      signature algorithm provides a limited assurance of authenticity
      at a given key strength.

      A.  A verifier MAY chose to evaluate signature records in any
          order it chooses, including making use of the signature
          algorithm for this purpose.

   o  The verifier MAY make a determination that Algorithm A does not
      offer a useful level of security, that the cost of verifying the
      signature is less than the value of doing so.

      A.  In this case the verifier ignores signatures created using the
          algorithm A and references to algorithm A in policy records
          are treated as if the algorithm is not implemented.

   o  The verifier MAY decide to add support for additional signature
      algorithms at any time.

      A.  The verified MAY add support for algorithm B at any time.

5.4.  Linkage to Other PKIs

   The principle limitations in DKIM are the lack of support for end-
   user keying, the lack of support for long term verification of
   signatures and the lack of support for trusted third party issued

Hansen, et al.          Expires December 20, 2006              [Page 21]

Internet-Draft                DKIM Overview                    June 2006

   assertions.  Each of these limitations is determined by the key
   distribution mechanism rather than the signature format.

   Although the DNS infrastructure could in principle be extended to
   support these features this approach would require substantial
   modifications that entirely negate the advantage of employing an
   existing infrastructure.  The point of using DNS is to reuse the DNS
   infrastructure, not the DNS protocol.

   The preferred approach to addressing these limitations is to support
   use of a PKI infrastructure designed to support these requirements
   such as PKIX, PGP or XKMS.

5.5.  Trusted Third Party Assertions

   A DKIM signature tells the signature verifier that the owner of a
   particular domain name accepts responsibility for the message.
   Combining this information with information that allows the behavior
   of the domain name owner to be predicted may allow the probability
   that the message is abusive to be determined without the need for
   heuristic content analysis.

   Recipients of large volumes of email can generate reputation data for
   email senders internally.  Recipients of smaller volumes of messages
   are likely to need to acquire reputation data from a third party.  In
   either case the use of reputation data is intrinsically limited to
   email sender which have established a prior history of sending

   Another commonly used technique for evaluating email senders is
   accreditation.  Most spam sent today is sent by criminals to further
   a scheme that is unambiguously illegal.  Spam demonstrates an
   Internet equivalent of Gresham's law: the bad spam drives out the
   merely irritating, the outright criminal drives out the bad.  A
   message is highly unlikely to be spam if the email sender that can
   demonstrate that it is a legitimate business and that it has provided
   a legitimate address where legal process can be served.  In addition
   the accredited email sender may accept a legally binding undertaking
   not to send spam and possibly post a performance bond that is subject
   to forfeiture in case of default.

   As with reputation data a high volume email recipient may be in a
   position to establish bilateral agreements with high volume senders.
   Smaller recipients are not in a position to require accreditation,
   nor is it practical for each large sender to accredit every sender.
   Trusted Third Party accreditation services allow an email sender to
   obtain an accreditation that is recognized by every email recipient
   that recognizes the Trusted Third Party.

Hansen, et al.          Expires December 20, 2006              [Page 22]

Internet-Draft                DKIM Overview                    June 2006

   [Need use of both systems]

   [Need means of advertising existence of positive reputation data]

5.6.  Linkage to X.509 Certificates

   The industry standard for distribution of Trusted Third Party data
   tied to a public key is the X.509v3/PKIX standard.  X.509 based PKI
   is designed to support requirements such as long term archiving of
   signatures, end entity signing and Trusted Third Party assertions.
   Combining the DKIM signature format with the PKIX PKI infrastructure
   provides an equivalent set of capabilities to S/MIME.

   Two approaches may be used to inform signature verifiers that an
   X.509 certificate has been issued that makes an assertion about the
   signing key for a DKIM signature:

   1.  By means of an attribute in the key record

   2.  By means of a signature header q= parameter

   Typical commercially issued digital certificates are considerably
   larger (1-2 kb) than the 512 byte message size that DNS servers are
   required to support as a minimum.  Practical large scale PKI
   deployment requires support for certificate chains in addition to the
   end entity certificate.  Publication of a URL for the certificate or
   certificate chain is therefore a more appropriate approach than
   storing the certificate data itself in the DNS.

   The ability to support multiple key distribution mechanisms for the
   same key is highly desirable.  For example a signer may support DNS
   based key distribution for the convenience and efficiency of
   transport based DKIM signature verifiers and an X.509 certificate

   In other cases a signer may intentionally discourage transport
   verification by only providing an X.509 certificate.

   An X.509 application of particular interest is the use of DKIM as a
   signature format for Secure Internet Letterhead (Letterhead).
   Letterhead employs X.509 certificates containing a LOGOTYPE attribute
   extension [LOGOTYPE] to identify the certificate subject and/or
   issuer to the user by means of a brand image such as a corporate
   logo.  [PHB-NIST]

5.7.  XKMS

   XKMS is a key centric PKI that supports registration and location of
   keys.  XKMS is layered as a Web service and the existence of XKMS

Hansen, et al.          Expires December 20, 2006              [Page 23]

Internet-Draft                DKIM Overview                    June 2006

   service for a domain is typically advertised by means of a DNS SRV

   XKISS, the key location component of XKMS provides a superset of the
   capabilities of the DKIM DNS key distribution mechanism.  As XKMS is
   layered on SOAP over HTTP over TCP/IP the overhead incurred in
   retrieving keys through XKMS is substantially higher than the single
   UDP request/response of DNS key distribution.

   Like X.509 XKMS is designed to key management over time periods of
   years and decades rather than days and supports the use of trusted
   third parties.  XKMS is designed to allow complexity to be
   concentrated at the Web service as opposed to the client.  A client
   interacts with an XKMS service using request of the form 'provide a
   key to verify signatures on messages sent by A using protocol B'.

   XKMS may also be used as a gateway to one or more PKIs including an
   X.509 based PKI that makes use of sophisticated features such as
   cross certification.  The verifier may at its option rely on the XKMS
   service to provide a trusted key or request the complete certificate
   path allowing offline verification.

   A signer may notify signature verifiers that a key may be retrieved
   using XKMS by means of the q= attribute.  The verifier may then
   discover the corresponding XKMS service using the SRV mechanism as
   setout in the XKMS specification.

5.8.  Verification in the Client

   The DKIM specification is designed to support edge to edge
   authentication.  The specification neither supports nor prohibits
   verification of DKIM signatures in the client.  In particular the
   specification does not attempt to define client semantics for
   signatures or provide an exhaustive list of user interface security

   For client based verification to be practical it is likely the a
   client needs to be capable of determining that it is able to receive
   messages that do not get clobbered before coming to any conclusions
   with respect to unsigned messages.

   DKIM requires that all verifiers treat messages with signatures that
   do not verify as if they are unsigned.  If verification in the client
   is to be acceptable to users it is also essential that successful
   verification of a signature does not result in a less satisfactory
   user experience than leaving the message unsigned.

Hansen, et al.          Expires December 20, 2006              [Page 24]

Internet-Draft                DKIM Overview                    June 2006

5.9.  Per user signature

   Although DKIM is designed to support domain level signatures the DKIM
   core design neither supports nor prohibits use of per user
   signatures.  A DKIM key record can specify restrictions on the email
   addresses it can be used to sign for.  These restrictions are not
   intended to be exhaustive nor are detailed semantics or security
   considerations set out for interpreting per user signatures.  The
   primary use this feature is intended to support is to allow a company
   to delegate signing authority for bulk marketing communications
   without the risk of effectively delegating the authority to sign
   contracts on behalf of the CEO.

   For per user signing keys to provide value beyond this limited use
   scenario it is likely that additional requirements are necessary such
   as the ability to perform long term validation of the key.  Linkage
   to some form of PKI is likely to be necessary.

   In addition any scheme that involves maintenance of a significant
   number of public keys will require infrastructure to support that
   management.  A system in which the end user is required to generate a
   public key pair and transmit it to the DNS administrator out of band
   is not likely to meet acceptance criteria for either usability or
   security.  As a minimum a key registration protocol must be defined.

5.10.  Encryption

   DKIM is not designed to support encryption.  A strong case can be
   made for applying the DKIM style of transparent security, key centric
   key management and domain level keying.  It is not clear that re-
   using the DKIM signature architecture is the best way to achieve this

   The DKIM signature format in particular is designed to allow meta-
   data to be attached to a message without modifying the content.
   Content encryption by its very nature requires modification of the
   message content.  The message encryption formats of PGP and S/MIME
   both solve the problem of message encryption perfectly adequately and
   there is no reason to believe that a new effort in this space would
   improve matters.

   An architecture of this form would require development of an email
   receiver security policy that allows a recipient to state that
   encrypted email messages are acceptable and to specify key
   distribution infrastructure(s) by which the necessary encryption keys
   may be discovered.

   A policy infrastructure of this type is implicit in the XKMS

Hansen, et al.          Expires December 20, 2006              [Page 25]

Internet-Draft                DKIM Overview                    June 2006

   standard.  One drawback to this approach is that policy distribution
   an key distribution are conflated, an approach hat is satisfactory
   for message level encryption schemes such as PGP and S/MIME but less
   satisfactory for transport layer encryption such as SSL.

5.11.  Reuse of Key Record

   A number of proposals have been made which attempt to reuse the DKIM
   key record.  Architects considering this approach should be aware of
   the advantages and limitations.

   As a minimum each of the security considerations listed in the DKIM
   specification should be considered and its possible relevance to the
   proposed field of use carefully evaluated.  Application of a security
   mechanism outside the context in which it was originally designed for
   is a principle cause of security failures.

   DKIM is designed to meet the security needs of an application where
   the cost of individual failures is insignificant or small.  A single
   spam in an email inbox is not a disaster, indeed it is no longer even
   an irritation.  For the long time spam sufferer who has seen their
   inbox filled with hundreds or even thousands of spams an occasional
   failure may even be cause for satisfaction, a reminder of a
   successfully vanquished foe.

   One of the chief limitations of using DNS based key records is that
   maintenance of DNS records is typically a network operations concern.
   If the entity to which the public key corresponds is a network object
   (e.g. a mail server) the use of DNS based key management is likely to
   be satisfactory.  If the entity is not a network related object (e.g.
   an end user) a significant degree of pushback from network
   administrators should be anticipated.

   The design of DKIM is designed for rapid deployment in response to an
   immediate need.  As such many of the design decisions are not the
   decisions that would be taken if the choice was unconstrained by the
   limitations of the current legacy DNS.  In particular the use of Base
   64 encoded public keys distributed through TXT records is not ideal.

   Applications that do not face the same constraints as DKIM should
   carefully evaluate the feasibility of using the binary key record.
   In particular an application predicated on the use of DNSSEC to
   authenticate keys should assume support for DKIM binary key records.

5.12.  Use of Policy Record

   DKIM demonstrates the power of using the DNS to distribute security
   policy information.  It is not possible to achieve robust security

Hansen, et al.          Expires December 20, 2006              [Page 26]

Internet-Draft                DKIM Overview                    June 2006

   unless the parties to a conversation know the security capabilities
   and expectations of the other.

   Any party proposing re-use of the DKIM policy record should carefully
   consider whether their needs would be better met by proposing a
   flexible security policy architecture in the DKIM style rather than
   proposing ad-hoc extensions and variations.

   At a minimum any proposal for new security policy formats that make
   use of the TXT record should employ a new policy prefix and ensure
   that mislabeled and wild-carded policy records are not accidentally

6.  What Needs To Be Moved Here From the Base Doc?

   MUA considerations

   key delegation/ 3rd party

7.  Acknowledgements


8.  Informative References

              Allman, E., "DomainKeys Identified Mail Signatures
              (DKIM)", draft-ietf-dkim-base-02 (work in progress),
              May 2006.

              Fenton, J., "Analysis of Threats Motivating DomainKeys
              Identified Mail (DKIM)", draft-ietf-dkim-threats-03 (work
              in progress), May 2006.

   [RFC0821]  Postel, J., "Simple Mail Transfer Protocol", STD 10,
              RFC 821, August 1982.

   [RFC0822]  Crocker, D., "Standard for the format of ARPA Internet
              text messages", STD 11, RFC 822, August 1982.

   [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.

   [RFC1848]  Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME

Hansen, et al.          Expires December 20, 2006              [Page 27]

Internet-Draft                DKIM Overview                    June 2006

              Object Security Services", RFC 1848, October 1995.

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

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

Hansen, et al.          Expires December 20, 2006              [Page 28]

Internet-Draft                DKIM Overview                    June 2006

Authors' Addresses

   Tony Hansen (editor)
   AT&T Laboratories
   200 Laurel Ave.
   Middletown, NJ  07748

   Email: tony+dkimov@maillennium.att.com

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

   Email: dcrocker@bbiw.net

   Phillip Hallam-Baker
   VeriSign Inc.

   Email: pbaker@verisign.com

Hansen, et al.          Expires December 20, 2006              [Page 29]

Internet-Draft                DKIM Overview                    June 2006

Intellectual Property Statement

   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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Hansen, et al.          Expires December 20, 2006              [Page 30]