[ietf-dkim] Proposed Charter, drop header authentication assertion.

[Douglas Otis]

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