Before responding, I want to clear up something that's been bugging me a
little lately. I've seen the unfortunate habit of speaking about something
called "SSP" as if it were foreign to or a mere enhancement of DKIM. In my
view, SSP is DKIM. It is the heart and soul of the proposal. It is the
thing which allows domain owners a say in the appearance of their domain
names in RFC2822.From headers. The "how do I create a signature" mechanics
exist to serve SSP yet we are speaking about that as if it were the only
thing this group need concern itself with.
If we are trying to solve the unauthorized appearance of YOUR domain name in
emails that people read every day, SSP is the mission-critical componant
here. If we are speaking merely about the production of another filter
input (this time one based on digital signatures) then SSP can be discarded.
What problem are we trying to address? Is it unauthorized use of my domain
name in email messages or is it the lack of a signature-based filter input?
So please understand, as things stand today, when one reads "DKIM" one is
reading of the SSP document and not merely the mechanistic "signature
algorithm" document. DKIM = "Signature algorithm" + "Sender Signing Policy"
+ "RR". DKIM != "Signature algorithm".
As a matter of simplifying the situation for some interesting
set of messages that are received, it is clear that folks
believe it useful to have a way of enforcing a linkage
between these two types of identities.
The base document is the only merely "useful" thing here. Rather,
characterize SSP as vital and essential.
The simple form of the test is:
If an originator's site invokes this linkage as a public policy,
and
if a message fails to satisfy the linkage,
then the message should be treated as having invalid
origination information.
That is a very good summary of the SSP aspects of DKIM.
In fact this requirement seems so basic and pervasive that
I am wondering whether it is necessary or appropriate to
restrict it to a particular authentication technique?
Unless or until a WG is chartered which successfully produces a generic
policy specification methodology, each authentication technique has no
choice but to specify it's own policy fetching mechanism.
Equally I am wondering whether it is not distracting from
the core DKIM authentication work to emphasize this
particular requirement prior to deployment of a signing/
validating mechanism.
There should be _no_ deployment of DKIM which does not also contain a
required SSP componant. There is no reason DKIM should be less effective in
protecting domain owners than DomainKeys or IIM. Such a fundamental, to the
core, change in DKIM, if allowed to take place, would render the output of
this group less effective in protecting the rights of domain owners than
either of the two proposals from whence it came. This move would insure the
continued existance (at least) of DomainKeys and it would quickly become
widely known that it was the IETF which stripped DKIM of its teeth. This
would be a lose-lose situation for everybody in my view.
Second, it isn't AT ALL as if the DKIM "how to create a signature" work is
"core" and SSP work is not. This thinking is backwards in my view. One
could easily argue that SSP topics are "core" and the "how to create a
signature" discussion is being handled first as simply the "path of least
resistance" to early achievement as an exercise in group dynamics. Both are
important. We must achieve the "core" DKIM authentication work and the
"core" DKIM SSP work both.
In other words, it is starting to look as if the mechanism
for enforcing originator/handling linkages needs separate
focus from techniques for performing authentication.
"Separate focus" sounds incredibly scary.
--
Arvel
_______________________________________________
ietf-dkim mailing list
http://dkim.org