On 1/7/11 12:37 PM, Barry Leiba wrote: > As the 4871bis editors worked on resolving the last sets of comments > in the 4871bis document, the chairs and the editors had some > discussion about other efforts that are interested in re-using > portions of the DKIM signing/verifying/key-distribution mechanism > outside the email context. See, for example, > http://tools.ietf.org/html/draft-desruisseaux-ischedule. This would > mean using a DKIM-like mechanism to secure the distribution of > scheduling events. That effort is currently referencing (and > updating) RFC 4871, but that includes what for them are many > irrelevant and inappropriate details that have to do with email. > > One way we can handle this and other use cases, as we move the DKIM > specification along, is to split the specification into two documents, > one that describes the underlying components, and a second that > describes the email-specific bits.
I'm quite unhappy with the proposal to split RFC4871, for a number of reasons (in no particular order): 1. Review Abuse: We held a Last Call on rfc4871bis that closed on 22 October 2010. Many of us put considerable focus into a detailed edit of the document at that time, and to hear that other than surgical changes to the document in response to Last Call comments is an abuse of many peoples' time, and not just mine. The cited other usage of DKIM signatures, iSchedule, was published in March 2010 so it should have not been the gating factor. 2. Charter: The DKIM WG charter states "1. Advance the base DKIM protocol (RFC 4871) to Draft Standard. This is the first priority for the working group." A reorganization of 4871bis into two documents is inconsistent with the "first priority" requirement of the charter. 3. Risk: The amount of violence that will need to be done to the text of RFC4871 introduces significant risk that the specifications will be unclear or inconsistent with 4871. While the rules for advancing to Draft do refer to specifications and not documents, I would be uncomfortable with doing anything other than recycling at Proposed to see if errata, etc. result from the changes. But recycling at Proposed is inconsistent with the charter. 4. Usage: DKIM has quite a bit that is tailored specifically for mail: the syntax of the header field, canonicalization, etc. The proposed split includes canonicalization as part of DOSETA, and wonder if that really makes sense. While the syntax of a DKIM signature may be close to what's required for iSchedule, will we next need to consider yet another split to permit signatures to be expressed in JSON, XML, or other formats? Are there other uses considered besides iSchedule at this time? 5. Security properties: DKIM was designed to provide a modest level of security limited by the security properties of DNS. This was considered acceptable because it's comparable to the level of security afforded message routing (since MX records could be spoofed). Other uses of DKIM need to be examined carefully to make sure that we do not depend on an insufficiently secure key infrastructure. While use of DNSSEC mitigates this, I'm concerned about whether it will really be used everywhere needed. 6. Redundancy: Section 10.1 of the iSchedule draft requires the use of TLS for all transactions. Why is DKIM then also needed (if the certificate verification happens in both directions, of course)? Why are two very different mechanisms in use? 7. Openness and Timeliness: Barry has apologized for not announcing this a month ago, but I sense that this has been going on in a private design team longer than that. BCP 9 section 1.2 talks to openness and timeliness; this fails on both accounts. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html