ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re-thinking the organization of the DKIM spec

2011-01-15 14:03:53
Having looked at the two drafts, although the idea seems reasonable, I
don't think we should do it.  At this point, as I understand it, any
application other than DKIM is hypothetical, which means we can't tell
where the split between generic DOSETA and specific DKIM should be.

As a concrete example, signing netnews messages seems like it should
be about as close to signing mail as you can get.  But relaxed
canonicalization, which is in DOSETA, is not useful for netnews, since
messages are not reformatted after injection, and changes of the sort
it allows are likely to indicate tampering.  Since usenet has a
longstanding forgery problem, I wouldn't want to allow SHA1, so I'd
rather not have that in DOSETA base either.

Yet i=AUID, which is made specific to DKIM, would be useful in the
common case that the author of a posting identified him, her, or
itself to the injection agent.  While we're at it, z= might be useful
for debugging.

You could move those items back and forth easily enough, but then the
next application comes along, say some sort of transaction log that
adds new entries at the bottom, and you want to apply signatures to
note the state of the log at particular times.  Oops, we need l= for
that, better move it from DKIM into DOSETA, too.

Let me repeat that I don't think that the curent split is necessarily
wrong, but I don't have any reason to think it's right, either.

Since we know what DKIM is, I'd rather keep DKIM-bis as one document,
and if it makes sense to do DOSETA, which strikes me as premature
until we have a better idea of what the applications are, make it a
short document that defines a subset of DKIM features by reference to
the DKIM spec.

Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet 
for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html