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