You are a bit late on that one. Other groups are already building stuff on top of DKIM key management. I have had more than one group ask me what the least bad way of doing this would be.
I like a specification that is defined as a series of independent modules with tightly defined interactions between them because that leads to good code. My view is that the DKIM protocol already meets that criteria. I think the spec would read more clearly if it was structured in that fashion, which to a large extent it already is. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of John Levine > Sent: Friday, August 12, 2005 12:30 AM > To: [email protected] > Subject: Re: Design approach to MASS (was Re: [ietf-dkim] On > per-user-keying) > > > >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 > > _______________________________________________ ietf-dkim mailing list [email protected] http://mipassoc.org/mailman/listinfo/ietf-dkim
