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, [email protected], 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
