Barry, Dave, and others,
Thanks for proposing this interesting split. As I'll discuss below, at
this point I think I have more questions than opinions. But I have at
least one opinion.
1. I recognize that sometimes good ideas have their own schedules, but
I consider it unfortunate that the WG had to spend time to go through
WGLC, resolve open issues, and then for the authors and chairs to
reorganize the work. I do think we're well beyond our charter, and that
we should consider this only in the context of rechartering. Such
consideration is always fair game.
2. The mechanisms in DOSETA were designed for DKIM. If we are
generalizing along the lines that Dave has mentioned, I would prefer
that DOSETA in particular not advance to draft status, as it ought to be
tested in at least two separate applications for a time. Otherwise we
run the risk of ossifying something prematurely.
3. It's at least worth a conversation to determine whether the split is
correct, and just how generally useful this will be. I have to believe
that Dave is motivated by more than just Bernard's draft. As I see it,
if we look at the DKIM key components, they consist of the following:
* Detaching the transport from the packaging.
* Retaining of signatures in the DNS, as opposed to a CA.
* Separation of meta-data (we call them headers) and content (we
call that body).
The innovation of DKIM is not any one of these things, but rather the
combination. The test question for me here, for instance, is whether we
can standardize the processing of the signature in DNS as separate from
how the signature is made. That is- can there be different types of
meta-information covered that does not take the form of headers/body?
4. Rather than keep it in the back of my head, I'll state it outright:
is a goal here to provide an alternative to SSL-based web page
security? Conveniently, web content does take the form of header/body.
If so, one reasonable question to ask would be whether there exist
characteristics and semantics of X.509 that would be necessary in this
context. For instance, is there sufficient surety given for, oh,
banks? And what would the UI implications be? Also, presumably it
would have implications to TLS relating to keying material.
5. As Mike Thomas and Jim Fenton alluded, the implications for such
frameworks extend well beyond this working group, and as such I would
recommend broad consultation with the security community.
Ok, I'll stop there for now. Seems like enough food for thought.
Eliot
On 1/7/11 9: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.
Note that progression along the standards track is for
*specifications*, not for documents, as such, so there's no reason
this split has to send us back to another cycle at Proposed Standard.
What's required is that we make no changes to the actual protocol (or,
at least, only changes that permit advancing to Draft). I've
discussed this with the Security ADs and the Applications ADs, and
they all agree that (1) such a split could be a good idea and (2) a
split that affects organization but does not change the specification
could still go directly to Draft Standard.
The editors have done some work on this to determine whether they can
split it safely, and they believe they have something suitable. The
chairs have asked them to post a detailed outline of their proposal so
that we can discuss whether the working group thinks a document split
is a good idea. We would like the discussion to focus just on that
point now, without getting to far into the details of the split,
beyond what's necessary to develop consensus for or against splitting.
We want to make this clear from the start: the chairs, the editors,
and (to the extent that they've thought about it, which is fairly
little at this point) the ADs think that splitting the document is
appropriate and useful... but it's the working group that will decide
whether to do it. Nothing has been decided yet, and it's up to the
working group. We'll need rough consensus FOR making the change.
Lacking that, 4871bis will stay as it is, as one document.
Please try to keep the discussion focused. Expect a message from the
document editors very soon, with the details of their proposed split.
Barry (and Stephen), as chairs
--
P.S.
I apologize for not making sure this got posted here for discussion a
month ago. The delay is my fault. [Barry]
_______________________________________________
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