The signing and canonicalization process can be specified independent
of key management components. The current DKIM draft interleaves
all of this throughout, when it does not need to be. A simple
restructuring of the document can fix this problem.
Since you asked for specific responses, I specifically respond that
attempting to subdivide DKIM into independent subsections is a
terrible idea. Please drop drop this pernicious proposal now.
I'm afraid I have to agree with this assessment.
The design point of the DKIM canon process is to come up with
something that works for DKIM. It most definitely is not to come up
with some general process that might be useful for some other
application that someone might think of in the future. Ditto the key
management. Attempts to generalize designs beyond the applications
they are intended for inevitably lead to heat death, which is why we
need to stamp them out now.
Saying that such an outcome is inevitable probably goes too far, but liklihood
of deadlock certainly would go up dramatically.
If it turns out that there are future applications that can reuse
parts of DKIM, that would be fine and they are welcome to plagiarize
whatever we come up with. But we must exclude such considerations
from the effort at hand in order to have some chance of completing the
project.
Or alternately, the specification could be revised and broken up later, once
it is clear that there's a need to reuse certain parts.
The MIME experience seems directly relevant here. The original MIME
specification consisted of only two parts. I think the splitup into five parts
was useful (although if I had it to do over there wouldn't be a part five),
but we simply didn't know enough at the time the initial document was
written to have chosen the boundaries properly.
Ned
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim