From: Jim Fenton [mailto:fenton(_at_)cisco(_dot_)com]
* Given the previous attempts to do this type of work why is DKIM
likely to be more successful?
I agree, there should be greater clarity with regard to realistic
defenses offered by the DKIM mechanism, especially in the
third-party
scenario you described.
Do you really agree? I read Phill's comment as "we could go
on forever, but this is pretty good now" while I read yours
as "needs improvement".
I think he is agreeing with my statement of the question but not the
answer.
As you know, I intend to take DKIM considerably further, but not in this
particular forum at this particular time. At this stage I want the MASS
group to produce just the engine. There are plenty of coachbuilders but
only one place where I can get the engine.
What DKIM does is to allow a party to accept responsibility for an
email message. This is very different to the traditional
S/MIME, PGP,
PEM, MOSS objectives.
...
Repudiation offers _minimal_ value when combined with an easy to
exploit mailbox-domain authorization scheme. Abusers will adopt
requisite conventions that defeat repudiation. Ascribing
repudiation
as a goal would be a mistake when reputation _must_ be applied as a
defense. However, with minor modification permitting replay
abatement, reputation should offer protection.
On good advice, I steered clear of the topic of repudiation.
Is there someplace the document implies repudiation protection?
DKIM offers responsibility, not repudiation.
Non repudiation is a useful objective in some contexts but these mostly
occur about three layers up in the stack from where DKIM works.
If you are interested in non-repudiation take a look at SAML. That would
be the starting poiint I would use. But even that requires a lot more
mechanism to be added to make a working system. Making email
non-repudiable by default is not a good idea.
Phill
_______________________________________________
ietf-dkim mailing list
http://dkim.org