On August 9, 2005 at 23:50, domainkeys-feedbackbase02(_at_)yahoo(_dot_)com
wrote:
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.
Ahhh. You're into assessing motives again. Here I was thinking you posted
your
email because you wanted responses - both positive and negative. Is it
because
I disagree with you that you classify me as defensive?
I guess email is bad to denote tongue-n-cheek comments. Your hammer
analogy was over the top.
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?
As it happens, that's precisely how the code at domainkeys.sourceforge.net
does
it already - consequently I'm a little confused about your point.
The point is, even in protocol design, it helps to identify components
that are independent of each other. It does not necessarily requiring
that such components be in separate documents (depends on the protocol
being developed), but the document(s) should be structured to show
where components are independent for potential reuse in other, related,
protocal development.
There are numerous IETF standards, or proposals, that take this
approach. I think the MIME RFCs is a good example. You think
that TCP/UDP/IP should have been combined together in a single
specification?
Another good example are cryptographic-based standards (e.g. PKCS)
where specific components are defined, independent of any specific
application. Public key cryptography methods did not have to wait for
a complete key management system (PKI) to be standardized. How to
create a digital signature of some data does not require knowledge
of a key management system.
It appears that creating message-header-based digital signatures
should not have to have any knowledge of a key management system.
Are you telling me you do not see any other applications besides DKIM
utilizing header-based signatures?
Well sure. But until they raise themselves in this forum are you suggesting w
e
should engineer for mythical requirements in preference to known requirements
?
Other usage scenarios have been raised, but there has been resistence
to even consider them from a protocol design perspective. For example,
future integration with XMKS and PKIX has been mentioned, providing
PKI facilities and the associated uses of having such facilities.
No one is advocating that such integration be part of the initial
set of deliverables, but it seems to be bad design practice to not
consider potential (forseeable) future uses and extension.
John states, "There is no surer way to destroy a standardization
effort than to start abstracting and generalizing the design."
I agree that this is a risk of any development effort, but also not
considering forseeable future usages and developments is another way
to kill something.
It is a balancing act, and I think not that much is being asked for
wrt DKIM.
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.
I guess I'm confused. You started with an unsubstantiated claim that DKIM
violates "basic software design principles" and when you get into specifics i
t
appears your main gripe is that the first incarnation of the key management
model is too specific for your liking. So what is the specific concern?
I have the impression there is resistance to any change in DKIM that
takes potential future development in consideration. Even basic things
like document restructuring and wording generates resistence, along
with reasonable advise of looking at other efforts and existing
standards in the development of DKIM.
For example, someone suggested I provide some example
rewording-restructuring of the draft to give a clearer idea of my
concerns. I only provided a small example of this because I feel it
is not worth the time and effort to do a full edit of the draft if
such effort will be dismissed. With the sample I provided, no one
provided in feedback that such rewording was acceptable or not.
All of which gets back to the same question. What problem are you trying to
coerce DKIM to solve? And why is that important? You allude to "definite
business interests" as a motivation. Can you be a little more specific?
The problems have been mentioned before, but it appears that you either
dismiss them or choose to ignore them. If DKIM solved everyone's
problem, why are people considering using XMKS or PKIX. Some would
like to have stronger security capabilities in header-based signatures
that go beyond what DKIM currently provides.
I think stating DKIM, as it is defined now, will be the only real
use for header-based signatures, there are many who will disagree
with this, including those puting some serious financial backing into
ventures that are looking beyond DKIM.
I definitely see a separation of the method for creating and
representing a message signature in email header field(s) from the
key management aspects of a particular application.
--ewh
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim