Bron Thanks for listening to my half baked ideas. Some small tweaks can be taken for what they are worth.
But this feels like the right balance - I vote for ship it to the IESG and let them soil it. tim On Thu, Nov 21, 2024 at 4:22 AM Bron Gondwana <brong= 40fastmailteam....@dmarc.ietf.org> wrote: > Thanks to all of you for great feedback on the first charter - > particularly to Dave and Tim! > > I have made a second pass at it. Text below, or see the raw copy at: > > https://notes.ietf.org/YGynIPpYS7yqg5G7ZeSQeA > > Cheers, > > Bron. > DKIM2 Draft Charter > Background > Emails often flow indirectly through multiple systems, undergoing > redirection, expansion into multiple copies via aliases and mailing lists, > as well as rewriting and filtering before eventually arriving at a mailbox > or being processed by a receiving software agent. > > DKIM gives us a way to detect that the content of a message was not > altered between the signing domain and its eventual destination. Several > attempts have been made to address the issues that arise with with > s/us/message systems/ (or something more neutral than 'us') s/arise with with/arise with/ <- fixed in raw copy alterations made by intermediate systems. For various reasons, these > technologies have failed to provide the information to reliably distinguish > between legitimate mail, and replay or alteration of messages by bad actors. > > Objectives > This working group will take a holistic approach to the underlying > problems of alterations, error handling, and trust relationships between > the systems involved in handling an email - from its inception to arrival > at its final destination. > s/problems of alterations/problems of message alterations/ > The working group will use the mechanisms of DKIM as a basis, extending > and modifying them to solve problems that have been identified in > real-world usage. > > It will be necessary for any new design to work in parallel with the > existing mechanisms, and have a clean upgrade path. > s/clean/clear/ ? > > To achieve its goals, this work requires a wide scope. The design may > supersede, modify, or replace many parts of the current email > infrastructure and associated reporting mechanisms - while retaining the > ability to support the same use-cases. > "same use-cases" - could this be "existing use-cases"? > Deliverables > To gain widespread adoption, it is expected that proposals will be tested > during the development of specifications. The working group will favor > designs that have been tested for interoperability at scale. > s/proposals/proposed solutions/ > This working group will produce multiple documents, at least: > > > - A overview document describing the problem area and proposed > mechanism (informational) > - One or more documents on implementation of the mechanism (standards > track) > - A guide for implementation during the changeover period, in which > interoperability with existing mechanisms needs to be maintained > (informational) > > This working group will also liaise with the DMARC working group on adding > this as a recognised authentication mechanism. > > Milestones > > - WG Formation: Dec 2024 > - Overview document: Jan 2025 > - Mechinism document draft(s): Mar 2025 > > s/Mechinism/Mechanism/ <- fixed in raw copy > > - > - Experiments and drafts: Apr 2025 - Nov 2025 > - Implementation guide: Nov 2025 > - Publish documents as a group: Dec 2025 > > > These dates are too tight but that's for others. What we do want to say is that the problem overview document be adopted etc by some date. tim >
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
