On August 9, 2005 at 23:50, [EMAIL PROTECTED] 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 [email protected] http://mipassoc.org/mailman/listinfo/ietf-dkim
