Rather than respond point by point I am going to throw out my thoughts on the
questions of what identity is being asserted and what I would like that
assertion to mean. I'll start with a fairly simplistic semantics which, if it
is even valuable as a starting point will need clarification.
My belief is that the identity we are interested in asserting/protecting is
that it is the identity of the domain of the 2822.From address corresponding to
the author of the message. The specific assertion being made is that this
domain has authorized use of their identity by the author of a message, for
that specific message. How a domain decides who to authorize to use their name
is beyond the scope of this group.
I don't think a hop-by-hop scheme effectively meets this goal. The minimum
"end-to-ended ness" needed would be from the border MTA of the original
2822.Sender to the border MTA of the final recipient of the message regardless
of the path the message took. I am not sure yet if this is at all functionally
different from a complete end-to-end solution except that it is explicit that
it must be possible for MTA's to handle the signing a verification.
One place where this differs from existing S/MIME implementations is that
ideally this system would be transparent to non-supporting MTA/MUA's. In other
words if your system signs all of its messages, but mine does not support
signature verification, then to the greatest extent possible it should appear
to me as if this intervening security step never happened.
Robert