Re: [ietf-dkim] DKIM charter update proposal

Coming back to this: I've still seen very little direct input on the
charter proposal.  JD likes it.  Dave made some specific comments,
which I responded to; there've been no other comments on what Dave's
said.  There've been no other specific proposals for changes to the
text.

Franck suggested gathering data on whether DKIM has been useful.  I
responded to that, saying that I don't think it's a necessary issue
for chartering at this stage.  Agreement or disagreement with that
would be useful.

Bill suggested looking at extensions for additional signature
delegation, Michael Hammer agreed, and a thread branched off from
there.  Is that still an active consideration for the charter, or not?
 Charles wants to see something more about guidance for mailing lists.
 Is that an active consideration?

Some have opined that it's even too early to consider taking the base
DKIM protocol to Draft Standard; let's make sure we have consensus on
that point, one way or the other.

I'd like to settle very soon on what, if anything, to do about
re-chartering.  Please address my specific points, above, so we can
get there.  And please keep the discussion focused on the charter,
without going into lengthy discussion of details of the work.

Barry, as chair

On Wed, Sep 30, 2009 at 12:00 PM, Barry Leiba
<barryleiba(_dot_)mailing(_dot_)lists(_at_)gmail(_dot_)com> wrote:
> Pasted below is my proposal for an updated DKIM WG charter.  Stephen
> has reviewed it and agrees, and now it's the working group's turn.
>
> I've kept two of the paragraphs from the original introduction,
> changing only the tenses, from things like "will produce" to "has
> produced".  I've turned the original deliverables list into a summary
> of what's been delivered.  I've put in new deliverables that basically
> amount to "advance the two protocols through the standards process, as
> appropriate."  And I've left the "this stuff is out of scope" section,
> because it's my sense that we still want to stay away from those
> items, at least for now.
>
> Please comment on it.  If you like it, please say so.  If you want
> changes, please specify, and suggest specific text.  If you don't
> care, and just want to get out of here, that's useful input as well.
> Let's define a two-week comment period, which we'll extend if
> needed... so, comment as soon as possible, and no later than Friday,
> 16 October.
>
> Barry, as chair
>
> ----------------------------------
> Domain Keys Identified Mail (dkim)
> ----------------------------------
>
>  Chairs:
>     Stephen Farrell <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
>     Barry Leiba <barryleiba(_at_)computer(_dot_)org>
>
>  Security Area Directors:
>     Tim Polk <tim(_dot_)polk(_at_)nist(_dot_)gov>
>     Pasi Eronen <pasi(_dot_)eronen(_at_)nokia(_dot_)com>
>
>  Security Area Advisor:
>     Pasi Eronen <pasi(_dot_)eronen(_at_)nokia(_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 (when done illegitimately, it's called
>  "spoofing"). The DKIM working group has produced standards-track
>  specifications that allow a domain to take responsibility, using
>  digital signatures, for having taken part in the transmission of
>  an email message and to publish "policy" information about how it
>  applies those signatures. Taken together, these will assist
>  receiving domains in detecting (or ruling out) certain forms of
>  spoofing as it pertains to the signing domain.
>
>  While the techniques specified by the DKIM working group will not
>  prevent fraud or spam, they will provide a tool for defense
>  against them by assisting receiving domains in detecting some
>  spoofing of known domains. The standards-track specifications do
>  not mandate any particular action by the receiving domain when a
>  signature fails to validate. That said, with the understanding
>  that guidance is necessary for implementers, the DKIM documents
>  discuss a reasonable set of possible actions and strategies, and
>  analyze their likely effects on attacks and on normal email
>  delivery.
>
>  The previously chartered deliverables for the DKIM working group
>  have been completed:
>
>  * An informational RFC presenting a detailed threat analysis of,
>    and security requirements for, DKIM. (RFC 4686)
>
>  * A standards-track specification for DKIM signature and
>    verification. (RFC 4871, updated by RFC 5672)
>
>  * A standards-track specification for DKIM policy handling.
>    (RFC 5617)
>
>  * An informational RFC providing an overview of DKIM and how it
>    can fit into overall messaging systems, how it relates to other
>    IETF message signature technologies, implementation and
>    migration considerations, and outlining potential DKIM
>    applications and future extensions. (RFC 5585 and
>    draft-ietf-dkim-deployment, in its final stages)
>
>  (One previously chartered deliverable, a standards-track
>  specification for DKIM DNS Resource Record(s), was dropped by
>  agreement between the working group and the Area Directors.)
>
>  The working group is now ready to switch its focus to refining and
>  advancing the DKIM protocols.  The current deliverables for the
>  DKIM working group are these:
>
>  * Advance the base DKIM protocol (RFC 4871) to Draft Standard.
>
>  * Collect data on the deployment and interoperability of the
>    Author Domain Signing Practices protocol (RFC 5617), and
>    determine if/when it's ready to advance on the standards track.
>    Update it at Proposed Standard or advance it to Draft Standard,
>    as appropriate.
>
>  As before, several related topics remain out of scope for the DKIM
>  working group. These topics include:
>
>  * Reputation and accreditation systems. While we expect these to
>    add value to what is defined by the DKIM working group, their
>    development will be separate, and is out of scope for the DKIM
>    working group.
>
>  * Message content encryption.
>
>  * Additional key management protocols or infrastructure.
>
>  * Signatures that are intended to make long-term assertions beyond
>    the expected transit time of a message from originator to
>    recipient, which is normally only a matter of a few days at
>    most.
>
>  * Signatures that attempt to make strong assertions about the
>    identity of the message author, and details of user-level
>    signing of messages (as distinguished from domain-level keys
>    that are restricted to specific users).
>
>  * Duplication of prior work in signed email, including S/MIME and
>    OpenPGP.
> ----------------------------------
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html