Design approach to MASS (was Re: [ietf-dkim] On per-user-keying)
earl at earlhood.com
Wed Aug 10 09:03:48 PDT 2005
On August 9, 2005 at 23:50, domainkeys-feedbackbase02 at yahoo.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
> email because you wanted responses - both positive and negative. Is it
> 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
> 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,
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
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
> 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
> > 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
> 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.
More information about the ietf-dkim