Technically speaking, decrypting email (your example) is easy. The
author must have had knowledge of your public key in order to generate
the mail in the first place. All you need to do, then, is decrypt with
your private key... no lookups necessary. Signature verification, on
the other hand, requires you to look up the sender's key. So does
sending an encrypted email. So yes, there is a real problem to
consider here.
In many cases, however, it is very easily solved. S/MIME emails carry
along with them the certificates necessary for
operation. And email clients typically archive the certificates that
they
have seen and used in the past. To get started, just send a single
digitally signed
email from one party to another, and your off and running (at least for
those two parties), no extranet directory
required at all.
That's the easy case. It presumes something that may or may not apply
for you. It presumes that the certificates used can be validated.
That is to say that there is a validation path from one user to the
other, through a certification authority or a chain of certification
authorities. This works fine where there is already a pre-established
relationship (or that we imagine one by going through VeriSign or
another "public" CA). I'm sure plenty other people can reply to you
about the details of certification authorities,
certification hierarchies and graphs, distribution of certificates,
certificate chaining, finding certificate
paths, etc, etc. If not, just shoot me an email. But the essence of
it is that you are presuming that there is a pre-established
relationship between the two parties sending emails to each other. If
so, then there can be a 3rd party that represents the relationship
between both parties communicating (two customers), called in this case
a "bridge CA", bridging the two companies certificate structures.
Putting aside the details of scoping of trust (which are in fact very
important), this can be the end of the solution.
Alternately, if there is no pre-established relationship, the solution
is the practical, common one. And it's based on a simple premise:
Before a relationship starts between two parties, neither of them have
any idea who the other one is, what "properties" the other person or
company has. There are no previous dealings to know about. Nothing is
yet known, not even the other parties name or true email address. At
this time, why not start fresh? Trust the other person with just one
thing: their public key. That tidbit of knowledge cannot be a lie.
There is an easy way to know that they hold the private component of it
(they can sign as themselves), and so they must be the "owner" of that
key pair. (This says nothing, however, about a subject distinguished
name they may put in for themselves if they distribute their keys in
the form of a certificate.) But at this point, you know absolutely
nothing about the other party, especially and including their name.
All you know is a
public-private key pair. OK, now start learning who is behind that key
pair. For instance... test their email address, ask for legal name and
address and verify with a credit reporting agency, etc, etc.
When you go to Amazon, for instance, and setup a new account, this is
exactly what they do. They let people "self register" and then use
that person's self-registered password (and account name) for future
reference, but they don't believe for a minute that these properties
say anything in particular about who you are... they start learning
(e.g. "enter your credit card information"). The PKI world seems
highly ignorant of (not unaware of, but simply "ignoring") this most
practical means of using public key technology.
Before I can give you any more details, you'll have to give more
details about what properties you are trying to achieve.
Specifically: Do you want to verify the source of the email back to a
legally liable entity? Do you have a pre-established relationship
with this entity? Do you have the ability to setup a bridge
certification authority between the two companies? Or do you want to
trust S/MIME emails from entities you've never dealt with before,
perhaps because there are lots of them and setting up lots of bridge
CAs is too expensive?
-Mike
licather@wellsfargo.com wrote:
Hi All,
I'm seeking expert opinions and
recommendations how to support S/MIME
communications in an extranet. Specially, decrypting an encrypted email
from
another company, i.e., the recipient needs to get hold of the
certificate of
the email author’s. Does that mean, there needs to be an extranet
directory
service to facilitate obtaining certificates? If not, what service
needs to be
setup to facilitate that?
Thank you in advance,
Catherine Li
CAST PKI Development
Wells Fargo
Services
Office: 415.243.6228
Fax: 415.975.6780
MAC: A0186-056
Email: licather@wellsfargo.com
This message may contain confidential and/or
privileged
information. If you are not the addressee or authorized to receive
this
for the addressee, you must not use, copy, disclose, or take any action
based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and
delete this message. Thank you for your cooperation.
|