RE: DKIM BOF -- draft charter and agenda

["Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>]

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@xxxxxxxxxxxx 
> [mailto:owner-ietf-mailsig@xxxxxxxxxxxx] On Behalf Of Barry Leiba
> Sent: Tuesday, October 11, 2005 2:22 PM
> To: ietf-mailsig@xxxxxxx
> Cc: leiba@xxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxx) http://www.research.ibm.com/people/l/leiba
> http://www.research.ibm.com/spam
>