Establishing a domain name that is accountable for a message being
offered is a problem for users of Internet mail when deciding whether
to accept the message. DKIM establishes a name that may acts as a
basis for trusting the content of the message and selected headers.
The DKIM working group will produce standards-track specifications
that permit authentication of a domain name associated with the
message using public-key signatures and based upon domain name
identifiers. This specification will also verify that selected
headers and message content has not changed subsequent to the domain
name association by way of the signature.
Keys will be stored in the responsible identity's DNS hierarchy. The
specification will be based on the draft-allman-dkim-*.txt Internet-
Drafts. The working group will make only the minimal changes deemed
useful to improve the viability of services that are based on these
specifications. The specifications will contain summaries of the
threats, requirements and limitations that are associated with the
specified mechanism. The DKIM working group will also address
mechanisms for advertising "signing policy" so that a recipient can
determine whether a valid message signature should be present.
The working group will NOT consider related topics, such as
reputation and accreditation systems, and message encryption. It
will also NOT consider signatures which are intended to make long-
term assertions (beyond the expected transit time of a message) nor
signatures which attempt to make strong assertions of the identity of
the message author.
The working group may also study whether to adopt a work item for
specifying a common mechanism to communicate the results of message
verification to the message recipient.
---
By not including the header forgery statement as the problem being
directly solved, and clearly indicating what DKIM actually does would
be helpful at avoiding a number of misunderstandings. This would
also clarify how DKIM is different from S/MIME or OpenPGP. While
indeed header forgery is a problem, DKIM does not directly address
this problem, however S/MIME or OpenPGP does. A great deal of time
has been wasted resulting from confusion created by suggesting this
mechanism directly addresses header forgery, when it does not. While
indeed DKIM prevents the signature header itself from being forged,
this is a new header and is not related to the existing problem of
email headers being forged. Even when mailbox-domains and the
signing domain match, no assurances are possible beyond the trust
established for the signing domain.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org