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
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim