ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Charter bashing...

2005-10-12 11:59:55
The other part of this that I admit to being confused by is in what
capacity Stephen is speaking -- bof chair, or just a contributor like
any of the rest of us. The charter Barry sent out was discussed at
length on the list and didn't seem especially contentious either on
the list or at the Paris bof -- the main contention was the lack of a
threats draft. Nor do I recall any pushback about the charter from
our AD's (?). So I'm not sure what a wholesale rewrite at this point
is actually attempting to accomplish. Are we really at risk of going
off into the weeds at this point if we don't revisit every point of
consensus we've accomplished in the last year or so?

      Mike


Dave Crocker wrote:

Folks,

Frankly, I think this is a huge step backwards. You're changing the charter from discussing the goals of the service we're trying to define to discussing the details of the mechanisms we use to build the service. IMO this is going down a path that is likely to cause far more problems than it solves, as it invites confusion with efforts to define very different services using similar
mechanisms.
...
The existing charter was careful to distinguish between service and
mechanism. Let's please try and keep that distinction.



This is a point that Ned has been stressing and I believe he is entirely correct. The benefit of having our discussions consider mechanics as "merely" secondary, so that we maintain a focus on goals/purpose, strikes me as massive.

DKIM is _not_ an alternate signature service, and that's precisely the point. DKIM only uses signatures as a means to an end, and the end is not to provide a nonrepudiatable signature covering the message. Rather, it is to provide a means whereby someone can assert responsibility for a message. This is a type of authorization service, not a signature service. We are forced to use digital signatures as a mechanism because the service has to deal with forgery and
replay attacks, but that's an (unfortunate) implementation detail.



The main reason I am posting this response is in the hope that folks will (re-)read the text of Ned's that I have quoted. I believe a very great deal of confusion will be avoided if we can all embrace this one, main concept that he has so nicely distinguished.

d/
_______________________________________________
ietf-dkim mailing list
http://dkim.org

_______________________________________________
ietf-dkim mailing list
http://dkim.org