Oh, good. I'm not the only party pooper. To what Jim wrote, I'll
add:
1) As a developer, multiple documents generally suck. IKE,
ISAKMP, and their friends. Need I say more?
2) Frameworks almost invariably fail, and that's what I sense
here. We gave some passing thought to making this usable
in other contexts, and heck I even wrote a SIP/DKIM signer
to tweak Fluffy's nose about sip-identity, but the reality
is that actually getting refactoring done in a way that
wouldn't ultimately require a new spin of one or more
documents is, IMO, close to hopeless.
3) Differing document maturity levels. You have one that's
advancing to draft, and one that one day may be PS. It just
doesn't seem reasonable to have those two be linked even
weakly.
I really don't see what the problem would be to take what
we did and just insert it as a whole and then start editing.
If this second use had come a couple three years ago, it
might have been worth considering to rationalize things, but
given how far along we are this is just setting up to be a
big fail.
Mike
On 01/10/2011 05:28 PM, Jim Fenton wrote:
> 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
>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
