Jim,
interesting comments.
However, the detail I now understand better is that we are
seeking an end-MTA to end-MTA signature mechanism, where one
end is "close" to the originator and one end is "close" to
the recipient. Yes, it may be that the originating MTA
signature can be validated at any point in the path to the
recipient, but I don't believe that's a primary goal.
I believe that there is no _requirement_ that signing be done by
the originating MTA nor that validating be done by the delivering
MTA. However it seems pretty clear that those are likely to be
the initial venues for these function.
I think it will prove essential to for the model to permit these
functions to be performed elsewhere, including the originating
MUA and receiving MUA, respectively.
I'm hoping this is what Dave meant by "transfer time"
i'm working on alternate language that will be less conducive to
misunderstanding...
Also, the primary goal is the creation of one signature, at
the originating MTA. A question to be debated in the working
group is whether intermediate MTAs should have the option of
of course, prior to that debate, there would need to be an
explanation of the purpose that would be served for the extra
complexity this multiple-signature capability would impose, as
well as agreement that it was worth the cost.
Overall, this is close to what MARID was doing but greatly
simplified, a huge win in my opinion.
For my own part, I think that this has pretty much nothing to do
with what Marid was attempting.
The spf/caller-id/sender-id flavor of schemes register the MTAs
in the transit path. In contrast -- as i know you know quite
well -- the scheme under discussion involves only two end systems
and none of the intermediaries. (Again, as i know you know, but
want to make sure others understand, this is a classic
demonstration of the distinction between channel-based schemes,
versus object-based schemes.
And I agree that the originating MTA signature means more
than just "I control the message." It means something along
the lines of "I'm asserting that I'm a valid source of email
from the email address in the Return-Path." The details of
The exchanges on this list have persuaded me that we do need to
get agreement on the rather precise semantics of the signature.
My feeling is that this needs to be done _before_ chartering,
because it is of such fundamental import to the work of the
group.
A simplistic example of two choices would be between a signature
based on rfc2822.From versus one based on rfc2822.Sender.
(My guess is that the actual utility of this scheme is not
affected much by the differences between these two, specific
choices. However I suspect that the public confusion that would
derive from not being clear the choice would affect deployment
and adoption. My own reason for not caring much about the
semantic difference between the two is that I suspect _any_
verifiable accountability will be sufficient. But this is just my
own intuition. That said, I suspect there are operational impact
differences that are significant.)
And, I think finally, there is the issue of the lifetime of
the signature. I sense there's some debate to be had on
whether the signature is valid after delivery.
There should probably be some clarity -- if not consensus --
about this, prior to chartering, because the impact of the choice
is likely to be so large.
First, developing an end-user to end-user signature mechanism
is explicitly out-of-scope.
Second, the purpose of this working group is to develop an
end-MTA to end-MTA signature mechanism.
Presumably you see major architectural, semantic and operational
distinctions between placing these functions in the end MTAs,
versus permiting them to be various locations, including MUAs.
Please explain.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker at ...
brandenburg.com