>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. 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. 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. R's, John _______________________________________________ ietf-dkim mailing list [email protected] http://mipassoc.org/mailman/listinfo/ietf-dkim
