Welcome to the ietf-mailsig mailing list. Below is the draft working group
charter we will be discussing at Thursday's MASS BoF at IETF-60.
-Jim
-----
Working Group Name: STRIVERS (Signatures for Transport Recognition of Imposture
in Viral Email and Repugnant Spam)
IETF Area: SEC
Working Group Chairs:
Document Editors:
(some subset of Jim Fenton, Mark Delany, Phill-Hallam Baker, Nathaniel
Borenstein, George Webb, ???)
Problem statement and WG Goals:
One of the many promising approaches to beating back the tide of spam, and in
particular to thwarting the insidious impersonation practice known as
"phishing," is the widespread adoption of digital signatures on email messages.
However, for over a decade the advocates of interpersonal digital signatures
have struggled with issues of adoption and use, so that only a small portion of
today's email messages are cryptographically authenticated in any way.
Several proposals have recently been published for a simple and automatic
mechanism by which outgoing messages may offer limited proof of
potentially-verifiable identity. Although there are already more than a few
mechanisms for attaching a digital signature to an email message, none meet the
particular set of constraints that are ideal for spam fighting. The ideal
signing mechanism for spam fighting would:
-- Facilitate automated signing of outgoing messages by any SMTP-initiating
entity.
-- Minimize computational and transactional overhead for high-volume email
servers.
-- Permit a high degree of anonymity when desired by the sender.
Several excellent proposals of this general nature have been published
recently, including:
DomainKeys, draft-delany-domainkeys-base-00.txt
Identified Internet Mail, draft-fenton-identified-mail-00.txt
E-mail Postmarks, http://www.lessspam.org/EmailPostmarks.pdf
MTA Signatures, http://www.elan.net/~william/mta_signatures.htm
Entity-to-Entity S/MIME, draft-hallambaker-entity-00.txt
The importance of converging on a single standardized mechanism is
difficult to overstate. This group will define such a mechanism.
Deliverables and Milestones:
The STRIVERS working group will design extensions to SMTP, RFC 2822, and
MIME that will enable any SMTP-sending entity to:
-- Convey the fact that a cryptographic signature is associated with
the message being delivered
-- Convey the identity and public key of the signing entity
-- Identify the precise message contents being signed (notably which
headers)
-- Deliver the signature along with the message
Additionally, it will define a possibly-optional mechanism by which an SMTP
receiver may verify the public key of an SMTP sender.
Finally, it will specify the appropriate best practices for SMTP senders
when they encounter (legacy) SMTP receivers that do not support the
STRIVERS mechanisms
The following work items are explicitly ruled out of the scope of
STRIVERS:
-- Address-based authentication; STRIVERS is intended to
complement MARID, and to be compatible with it if the two overlap or
intersect in any way.
-- Rating services for conveying reputational information about
the signing entities
Proposed Timeline:
Jul 04 Establishment of mailing list, preliminary discussion
Aug 04 BOF meeting at San Diego IETF. Selection of WG leaders & document
editors
Sep 04 Publish signature syntax proposals for discussion
Sep 04 Publish protocol extension proposals for discussion
Oct 04 Interim meeting. Identification of major open issues
Nov 04 WG meeting at Washington IETF. Resolution of major open issues.
Jan 05 Publish first drafts of "consensus" documents
Feb 05 Publish more drafts of "consensus" documents
Mar 05 Publish more drafts of "consensus" documents WG Last Call
Mar 05 WG meeting at IETF conference. Publication of RFC as Proposed
Standard.
Mar 06 Publication of RFC as Draft Standard.
Mar 07 Publication of RFC as Full Standard.