--- George Gross <gmgross(_at_)nac(_dot_)net> wrote:
Why not tunnel the e-mail message body and its "origin" e-mail header
info into a S/MIME payload, sign it, then add a new outer tunnel e-mail
header in front of that payload, and then e-mail it? The inner e-mail
header remains separate from the outer header and therefore unmangled
while in transit.
The question is, who un-tunnels (or perhaps more correctly un-encapsulates) an
email once the sender encapsulates it?
Let's say I start at my UA and send a message with the following contents:
SUBSCRIBE IETF-MAILSIG(_at_)IMC(_dot_)ORG
and my MASS-aware MSA nicely S/MIME encapsulates it for me.
Assuming you don't expect every listserv on the planet to be upgraded before I
can send this in S/MIME, then some intervening party has to do the
un-encapsulation for the listserv, yes? Which party does the un-encapsulation
and how does it now to do it?
What about for a listserv that is MASS aware? How does the intervening party
learn this and not do the un-encapsulation?
In the forward direction, what if my UA is MASS aware? It may well encapsulate
email prior to submission. Should my MSA encapsulate my encapsulation, or
un-encapsulate then re-encapsulate? Should my UA know whether my MSA will do
this for me and avoid encapsulation if supported by the MSA? How does my UA
learn about the MASS capabilities of the MSA?
In the transit area, what if the message is sent to a MASS-unaware MTA? Does
the message have to be un-encapsulated by the sender (and thus lose the
authentication information) or can we assume the final recipient is aware? If
the sender has to un-encapsulate, presumably the recipient MTA has to tell the
sender in some way? Is that via an ESMTP extension? Will secondary MXes have to
learn about what the primary MXes can support? How will they learn this?
In a sense that is that same question applied to naive forwarders.
It may be that POBOX.COM and acm.org never support MASS, but the end-points
beyond POBOX.COM may well do. Is that just bad luck for the end-points beyond
POBOX.COM and acm.org?
What about a UA that S/MIMEs it's own message for other reasons, such as
encryption or higher level security for financial contracts? Presumably an MSA
would encapsulate that encapsulation. At the un-encapsulation point, how does
the recipient now how many levels to undo?
What does an ISP that receives email for many different users and many
different domains do? Do they always un-encapsulate or do they learn about the
UAs and domains on the other side of (eg) a POP session or an IMAP session or
evan a UUCP over TCP session and make decisions that way?
The point being, as soon as you introduce a disruptive encapsulation system
like S/MIME you fundamentally break most present day UAs (where UAs can easily
be scripts and other programs, not just people).
Therefore, to protect against that breakage, you have to define
un-encapsulation points that cover all possible transit cases and invent
communication mechanisms that tell exchanging parties whether they support that
encapsulation or not.
That sounds extremely messy to me and I don't quite get the benefits. After
all, S/MIME is not deployed or implemented on most Internet email servers, it
was never really designed for this application and the profile needed to
support MASS doesn't even exist!
Sure, we can bludgeon S/MIME to fit, but you would be discarding most of the
interesting parts of S/MIME, having to invent most of the missing bits such as
key fetching, header support and a new profile. And, you have to invent a whole
bunch of rules, procedures or protocols to cover de-encapsulation points. That
doesn't sound like S/MIME to me, that sounds like an unpleasant son-of-S/MIME.
So I think you're question should be put around the other way. What
justification is there for even considering a disruptive encapsulation system?
Mark.