On August 9, 2005 at 21:46, [EMAIL PROTECTED] wrote: > > A core problem with DKIM is that it combines several components > > together when they can be separated, allowing for greater flexibility > > and choices. DKIM violates basic software design principles. > > You mean a simple, utility-specific, easily-implementable specification goes > against the grain of basic software design principles? Is that like saying a > hammer is a bad choice for driving nails because it's not flexible enough to > apply paint to walls?
A little defensive, aren't we. Are you telling me that the digest and canonicalization components would not be separated out in your implementation where they can be tested as separate units and be unaware of any DKIM-isms? Are you telling me you do not see any other applications besides DKIM utilizing header-based signatures? > I guess my question is: Why do you want greater extensibility? What problem a > re > you wanting to solve? Is the specific problem that DKIM attempts to address, > not important enough and not complex enough to justify having a simple, > tailored solution? The name "DKIM" implies a particular usage model for header-based signatures. Contrary to what you may believe, there is definite interest by those participating in these discussions to extend DKIM, as it is currently defined. Also, there is definite business interests looking to go beyond DKIM. Contrary to what the S/MIME or OpenPGP advocates might believe, market forces appear to be moving towards header-based signatures with some usage overlap with S/MIME and OpenPGP. Although there are some inherent limitations of header-based signatures that S/MIME or OpenPGP do not have, it is inevitable that header-based signatures will be used for operations that were initially considered within the domain of S/MIME and OpenPGP. Therefore, it appears wise to try design specifications for header-based signatures that is not tied to a specific key management model, which DKIM currently does. When there are components that are not specific to the DKIM application model, it seems remiss to bind such components to DKIM. As has been mentioned on the ietf-mailsig list, integrating with systems like XMKS and PKIX is desirable (and I know Phillip is not alone in this). Also, variants, like including the public key within messages instead of DNS, may be useful. Note, I am not arguing against the DNS-based key management model. It definitely looks worthy to define. However, it should not be the end-all be-all of MASS work. As I, and others are saying, we are not advocating the definition of other key management systems or accreditation systems as part of the first set of deliverables. What we are asking for is a design that is modular and allows for reusability and extensibility so such system (especially ones that are already defined) can be hooked in. BTW, maybe it is the name "DKIM" that is the problem. As I have noted before, the DKIM specifications can be reworded and restructured (and a few changes) to show that it is flexible. But it would seem odd for extensions that do not rely on a DNS-based key management system to be based upon a standard whose title implies it is. It will also be a waste for other header-based signature initiatives to have to re-specifiy digesting, canonicalization, and signing algorithms each time when most of the work to define such things has already been done. --ewh _______________________________________________ ietf-dkim mailing list [email protected] http://mipassoc.org/mailman/listinfo/ietf-dkim
