Skip to main content

DomainKeys Identified Mail (DKIM) Signatures
draft-ietf-dkim-rfc4871bis-15

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    dkim mailing list <ietf-dkim@mipassoc.org>,
    dkim chair <dkim-chairs@tools.ietf.org>
Subject: Protocol Action: 'DomainKeys Identified Mail (DKIM) Signatures' to Draft Standard (draft-ietf-dkim-rfc4871bis-15.txt)

The IESG has approved the following document:
- 'DomainKeys Identified Mail (DKIM) Signatures'
  (draft-ietf-dkim-rfc4871bis-15.txt) as a Draft Standard

This document is the product of the Domain Keys Identified Mail Working
Group.

The IESG contact persons are Sean Turner and Stephen Farrell.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-dkim-rfc4871bis/


Ballot Text

Technical Summary

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

Working Group Summary

Getting this document finished has been a controversial process, with strong
disagreement about a number of points. There is certainly broad agreement that
DKIM is a widely deployed, useful protocol, and that it's ready for advancement.
There are major differences of opinion on several things, including

1. The importance of giving specific advice on which email header fields to sign.

2. What information should be considered "output" from the signature verifier.

3. How the DKIM signature ties into, or should tie into, domain names that appear
in other parts of the email message, particularly the RFC 5322 "from" header
field.

4. How to handle potential attacks mounted by adding extra header fields
to the message after it has been signed. This is a particular issue with the RFC
5322 "from" header field, but affects other header fields as well.

There have been other controversies; this list is not exhaustive. See the
mailing list archives for more details. In the end, though, the document as
submitted has rough and significant consensus of the working group as a whole,
even when it doesn't represent unanimity.

Document Quality

The DKIM base protocol is widely deployed, with many implementations (see
http://www.ietf.org/iesg/implementation/report-rfc4871.txt ). This version of
the spec comes after a thorough working group review and publication of RFC
5672, which added significant clarifications to the language. 

Diffs between RFC 4871 and this draft can be found at:

   http://www.trusteddomain.org/dkim-diff.html

Personnel

Barry Leiba (barryleiba@computer.org) is the Document Shepherd.
Sean Turner (turners@ieca.com) is the Responsible Area Director.

RFC Editor Note

Note that draft-ietf-dkim-mailinglists depends heavily on
draft-ietf-dkim-rfc4871bis, and will be waiting in the editor queue for a
reference to it.  That document has references to specific sections in
draft-ietf-dkim-rfc4871bis, so the RFC Editor should process rfc4871bis
first, and make sure the section references in dkim-mailinglists are
correct afterward.

RFC Editor Note