The most important thing we have to do before the BOF is to get some
consensus on a charter for the proposed Working Group, and set an
agenda for the BOF. To the first end, let me start by posting the
current version of the post-Paris draft charter. I think a few changes
to it will help, and I know Stephen has some quite significant comments
and changes that he'd like to see, so let's bat this around and try to
wind up with something we can go with by the end of this week.
The main changes that I think are needed are these:
* I think the intent of this sentence has been widely misunderstood:
"The working group will make only the minimal changes deemed useful to
improve the viability of services that are based on these
specifications."
...and I'd like the clarify it. The point is not that we want to limit
discussion to moving commas. The point is that there's a significant
deployment of some of this already out there, and we'd like to maintain
compatibilty with that installed base, to the extent that it's
reasonable to do so. If an incompatible change is Really the Right
Thing, we should do it. But let's be sure that it's Really the Right
Thing.
So I'd like to see wording that clarifies the intent there.
* I want to make it much clearer, right in the charter, that no one
thinks this will "stop spam", and that that isn't the intent of the
spec nor the goal of the Working Group. We do mention forgery, but I
don't think we point out clearly enough that it's the forgery that this
is addressing, and not other aspects of spam fighting.
Stephen and I also talked about adding an informational document to the
deliverables, and I'll let him talk about that some more when he
responds here.
Also: I know the milestones are extremely aggressive, and that's
intentional. Those of us who've worked on getting this far want to
move this work along *quickly*, because we believe that it's a critical
component of the anti-spam/anti-phishing toolbox, and that we need it
*now*. That said, let's look at those dates and accept "aggressive",
but make sure they're feasible.
OK, let's get started. What do you think?
Barry
--
Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
DRAFT IETF WORKING GROUP CHARTER
22 Aug 2005 0932
Domain Keys Identified Message (DKIM)
CHAIRS:
TBD
AREA DIRECTORS:
Russell Housley, Sam Hartman
AREA ADVISOR:
Russell Housley <[EMAIL PROTECTED]>
MAILING LISTS:
General Discussion: [email protected]
To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim
Archive: http://mipassoc.org/pipermail/ietf-dkim/
DESCRIPTION OF WORKING GROUP:
Forgery of headers that indicate message origin is a problem for users of
Internet mail. The DKIM working group will produce standards-track
specifications that permit authentication of message headers during transit,
using public-key signatures and based on domain name identifiers. 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.
GOALS AND MILESTONES:
7/05 Issue initial Internet-Draft[s] of signature specification
10/05 Submit to IESG - for DKIM threats and requirements
2/06 Submit to IESG - DKIM signature specification
2/06 Submit to IESG - DKIM public key Resource Record
5/06 Submit to IESG - DKIM policy specification
_______________________________________________
ietf-dkim mailing list
http://dkim.org
