I would suggest we take the language from Jim's threat's doucument to
describe the purpose of the group.
We are not doing an old-style access control based security scheme. We
are descigning an accountability based security scheme.
The purpose of DKIM is to allow parties to accept responsibility for an
email message. That is all.
Accepting responsibility allows a party to establish reputation and if
they establish a positive reputation to increase the probability their
email will be accepted.
I would strongly suggest that the charter:
1) Define its scope as 'allowing parties transmitting email messages to
accept responsibility for them'.
2) State that the specifications developed will be compatible with the
deployed DKIM base unless there are very strong reasons to do otherwise
3) State that with the exception of the signature header, key and policy
records already proposed, the group will not develop new protocols,
define new message formats or define new profiles of existing protocols
or message formats to apply them to a different purpose.
4) State that the group may specify the means of interaction with
existing standards that might be expected to interact with DKIM.
Phill
-----Original Message-----
From: owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Barry
Leiba
Sent: Tuesday, October 11, 2005 2:22 PM
To: ietf-mailsig(_at_)imc(_dot_)org
Cc: leiba(_at_)watson(_dot_)ibm(_dot_)com
Subject: DKIM BOF -- draft charter and agenda
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
(leiba(_at_)watson(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam