OK, I've let this simmer for a couple of days, and I think it's time
to come back with my take on it, as the other BOF chair, and as someone
who's worked on the specs as they currently are. I'm including Russ
as a CC on this message, asking him (Hi Russ!) explicitly to comment.
As I said in my previous note, I had a couple of issues with the
draft charter as it was, and I agreed with some of Stephen's comments.
I also agree with what Dave, Jim, Mike, and some others have said about
questioning the value of a too-extensive rewrite of the charter (though
that might be what I'm posting here anyway, since I tend to rewrite,
when I get my hands on stuff). I think I've got a good compromise,
which I'm attaching here.
It keeps the general flavour of the original charter, and expands
the text a bit in the areas where some have said it's lacking. I've
rearranged and reworded some things, without, I hope, completely
changing it. And I've revised the milestones to be what I think are
feasible, and still aggressive.
I left out two points (perhaps more, but I'm sure he'll point that
out) that Stephen had put into his version with a "?" on them: those
involving doing additional work on canonicalization and cryptographic
transforms. I think the specs allow us to plug things in here, and
that work on them doesn't need to be explicitly called out in the
charter. If people disagree, I'm sure they'll say.
Russ: What do you, who will need to approve the charter, think about
this pass? Do you think it's reasonably solid, and takes into account
the major comments that've been made? Would you be comfortable with
a working group with this charter?
Everyone: Pretty much the same questions. Does this reflect what
most of us think? Does it adequately explain what we're trying to do,
and not trying to do? And do the milestones seem feasible?
Barry
--
Barry Leiba, Pervasive Computing Technology
(leiba(_at_)watson(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
DRAFT IETF WORKING GROUP CHARTER
13 Oct 2005
Domain Keys Identified Message (DKIM)
CHAIRS:
TBD
AREA DIRECTORS:
Russell Housley, Sam Hartman
AREA ADVISOR:
Russell Housley <housley(_at_)vigilsec(_dot_)com>
MAILING LISTS:
General Discussion: ietf-dkim(_at_)mipassoc(_dot_)org
To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim
Archive: http://mipassoc.org/pipermail/ietf-dkim/
DESCRIPTION OF WORKING GROUP:
The Internet mail protocols and infrastructure allow mail sent from one
domain to purport to be from another. While there are sometimes legitimate
reasons for doing this, it has become a source of general confusion, as
well as a mechanism for fraud and for distribution of spam (and is, in this
context, called "spoofing").
The DKIM working group will produce standards-track specifications that
allow a domain to take responsibility for having a part in the transmission
of an email message, using digital signatures, and to publish "policy"
information about how it uses those signatures. Taken together, these will
allow receiving domains to detect (or rule out) spoofing in many
circumstances. The specifications will also contain summaries of the
threats, requirements and limitations that are associated with the specified
mechanism.
While the techniques specified by this working group will not prevent fraud
or spam, they will provide a valuable tool for defense against them by
allowing receiving domains to detect spoofing of known domains. What to do
with that information is still left to the receiving domain, and this group
makes no attempt to define that, or to establish trust relationships, or
reputation of accreditation systems.
The signatures will use public-key cryptography and will be based on domain
name identifiers. Keys will be stored in the responsible identity's DNS
hierarchy. The specifications will be based on the following Internet
Drafts:
* draft-fenton-dkim-threats
* draft-allman-dkim-base
* draft-allman-dkim-ssp
which represent experimentation and consensus from a number of designers and
early implementors. Because there is significant deployment on the Internet
of these specifications, as part of the experimentation, the working group
will make every reasonable attempt to keep changes compatible with what is
deployed, making incompatible changes only when they are necessary for the
success of the specifications.
The working group will NOT consider related topics, including, but not
limited to, the following:
* Reputation and accreditation systems. While we expect these to add value
to what is defined by this working group, their development will be
separate, and is out of scope for this group.
* Message encryption.
* Key management, including key-distribution infrastructure.
* Signatures that are intended to make long-term assertions beyond the
expected transit time of a message.
* Signatures that attempt to make strong assertions about the identity
of the message author.
* Duplication of prior work in signed email, incuding S/MIME and OpenPGP.
* Details of user-level signing of messages. While the specifications may
allow for extension to user-level signing, this group is specifically aimed
at the domain level.
Once the primary goals are met, 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.
The deliverables for this working group will be
* an informational RFC providing an overview of the area and of DKIM
* an informational RFC presenting a detailed threat analysis of DKIM
* a standards track specification for DKIM signature and verification
* a standards track specification for DKIM policy handling
* a standards track specification for a DKIM DNS Resource Record
GOALS AND MILESTONES:
7/05 Issue initial Internet-Draft[s] of signature specification (done)
11/05 Vancouver BoF
01/06 WG formed
02/06 WG last call on DKIM threats and requirements
05/06 WG last call on DKIM signature specification
07/06 WG last call on DKIM policy specification
12/06 WG last call on DKIM DNS Resource Record
12/06 WG last call on overview document