On August 9, 2005 at 21:46, domainkeys-feedbackbase02(_at_)yahoo(_dot_)com
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
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim