Sorry for waiting another day to respond. I have read all the
responses. Along the way I understood something I had not quite
internalized before that helped me a lot.
I'll still reply to a few of the messages, some privately just so I
don't repeat myself on the mailing list, but, since this is a charter
discussion, I thought it would be most expedient to give my now
clarified position.
I am still opposed to an end-to-end email signature mechanism, more
precisely, an end-user to end-user mechanim. I still believe that to do
so would be re-inventing secure email.
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'm hoping this is what Dave meant by "transfer time" mechanism. If so,
let's be more specific. If not, well, perhaps this discussion isn't
over.
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 adding their
signature, what it means to do so, and then how a receiving MTA deals
with the multiple signatures.
Overall, this is close to what MARID was doing but greatly simplified, a
huge win in my opinion.
I still assert that S/MIME and PGP can be part of a solution to this
problem, but I think it was John Levine who asked the question of what
happens when the receiving MTA doesn't understand MIME or the embedded
body part. I'm not convinced that's serious issue, but that's a good
question to debate in the working group.
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 that are something that should be debated
in the working group.
And, of course, there is still the whole issue of key management, but I
don't think there's been any disagreement that that is something to be
debated in the working group, with a preference towards using the DNS.
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.
If I've got all that right, then what I would most like to see the
Charter say is two things.
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.
I'm okay with all other issues being left for debate.
Thanks!
Jim