Hi,
you've asked alot of good questions, and I won't pretend that all
of them have an off the shelf answer. I simply haven't thought about all
the nooks and cranies of this solution. However, I think there is enough
known about how to make S/MIME viable that it should be explored, contrary
to what the tenor of your response would suggest...
You asked several fundemental service discovery kind of questions, here is
a synopsis of existing tools I know of that could solve that aspect of
this problem. For that matter, other tools that I don't know of may be
available.
In a nutshell:
1) The e-mail originator does not S/MIME encapsulate an e-mail unless the
destination domain name has an IPSECKEY Resource Record containing a
valid public key for S/MIME de-encapsulation services. Several points to
clarify about this step:
- The IESG has just approved for RFC publication a proposed standard
for the IPSECKEY RR. While initially developed for opportunistic IPsec, it
is extensible. In this application, the public key field of the RDATA
would be the X.509 certificate of the S/MIME decapsulator (or a pointer
to the certificate's repository). See the draft: ipseckey-rr-11.txt
- There needs to be a valid X.509 certificate chain between the S/MIME
decapsulator and the S/MIME encapsulator who will be signing the e-mail.
It makes no sense to S/MIME encapsulate unless the e-mail source knows
that the S/MIME decapsulator can successfully validate the signature. My
sense is that cross-certifying on a common set of trust anchors is a
kettle of fish best tackled by an operations-oriented working group. This
is the global PKI problem, but then this is same mountain that every MASS
proposal has to climb.
- The SubjectAltName field of the S/MIME decapsulator's certificate
contains an ID_RFC822_ADDR which becomes the destination e-mail address
(i.e. outer tunnel destination) of the S/MIME encapsulated e-mail. The
X.509 certificate should probably also have an extended key usage field
value that authorizes the use of this public key in this application.
- From an overhead avoidance perspective, it makes sense to have the
end user MUA handle the S/MIME encapsulation, as that distributes the
cryptographic and certificate path validation overhead across the end user
community originating and signing the e-mails. OTOH, a MSA that is capable
of handling the load could proxy this processing on behalf of the end
users and centralize the key management administration. I would expect
that this is an operational policy decision.
- Although this IPSECKEY approach works at the domain level, there is no
reason why an end user to end user approach can not work too. The
destination end user would publish an X.509 certificate containing his/her
2nd individual e-mail address that he/she created for handling S/MIME
decapsulation. If you want to make the certificate's search key
predictable, you can invent a convention for algorithmically assigning
this 2nd e-mail address (e.g. the S/MIME decapsulator user id is the hash
of the user id portion of the primary e-mail address). User to user
certificate distribution mechanism is the same as S/MIME today, no better
or worse. I could e-mail to you my S/MIME decapsulator certificate as an
attachment. Or you could do an LDAP query. Or a HTTP cert retrieval.
2) At the destination domain, the S/MIME decapsulator receives the e-mail,
strips off the outer header, and it does signature verification on the
S/MIME payload. If the signature verifies, then it delivers the e-mail to
its ultimate recipient. For the majority of cases, I would expect that the
end recipient does not need to view the S/MIME signature. Of course, local
policy may allow the MUA to (re-)do the S/MIME decapsulation and signature
verification.
3) For e-mail list servers, it seems like you would want to selectively
re-encapsulate for those e-mail list members whose domain does support
S/MIME decapsulation service.
Of course, the acid test is whether the overhead of S/MIME and certificate
processing (or any MASS proposal) is lower than traditional anti-spam
filtering ;o)
hth,
George
On Sun, 3 Oct 2004 domainkeys-feedbackbase01(_at_)yahoo(_dot_)com wrote:
--- 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.