Re: [ietf-dkim] Re: DKIM BOF -- draft charter and agenda

I'm also fine with this (modulo whatever wordsmiting happens).
It addresses the main issues I raised, seems to me to reflect
the list-discussion nicely, and is I believe generally good
enough to start work from.

My only nit worth a mention would be to push the 07/06 milestone
back to 09/06 to give some time after the summer 06 ITEF for the
editor to tidy up. All the other milestones seem to give the
editors that chance and I think its generally an ok way to do
last-calls.

As to the additional crypto/C14N stuff - if its really necessary
in separate docs. then we can ask for a recharter, I was just
suggesting shortcutting that up front.

Stephen.

Barry Leiba wrote:
> 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
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ietf-dkim mailing list
> http://dkim.org
_______________________________________________
ietf-dkim mailing list
http://dkim.org