Steve,
Steve Hole wrote on 08/14/2003, 10:30:
Well, for the first time in a long time my interest is up on this
list :-). What a wonderful topic! General purpose use of
S/MIME by the masses on the Internet. Why hasn't it happened and what
can we do about it.
Yes, that's exactly the problem that prompted my questions. And it's
coming soon to an AOL mail program near you ... Some of you may have
heard of this new "AOL Communicator" mail program that was released in
the last week to the masses. In fact this program already includes
S/MIME support.
Hopefully, solving this problem doesn't necessitate new specs and
completely new services and products, but only minor tweaks and
clarifications of how to use the existing technology.
On Wed, 13 Aug 2003 19:29:53 -0700 Julien Pierre
<jpierre(_at_)netscape(_dot_)com>
wrote:
This highlights one of the key issues. It is easy enough to exchange
keys simply by sending a signed message, but there are some significant
barriers:
1. What if your encryption key is separate from your signing key. This
is not only common but considered good security practice. How does one
go about exchanging/discovering the encryption key for the new party you
want to exchange mail with.
This is supported today in Mozilla mail, Netscape 7.x mail, and AOL
Communicator.
In fact, in our internal PKI deployment we use different keys for
encryption and signing. This results in the issuance of two different
certificates, one for signing and another for encryption.
The digital signature can be configured to include a different
certificate for encryption. Look at my signature in this message and see
if you get confused : I signed it with my corporate certificate, but I
included a recipient Thawte encryption certificate.
2. Timeliness of the key exchange. The problem with mutual signing
exchange is that the other person has to respond to you. What if you
just
want to send them an encrypted load right off the start. You can't
really do it.
That's right, and it's the whole problem I have been asking about.
Exchanging unencrypted messages first, in my opinion, is not a solution.
The solution is (and always has been) to do a lookup. The problem is
that
there is no directory to look up from. Global X.500/LDAP directories
are
*never* going to happen.
Why ?
There is only one choice -- DNS. I (and Steve Kille and others) have
been flogging LDAP directories and working on LDAP/X.500 interconnects
for
a decade. Global X.500/LDAP isn't going to happen in our lifetime.
Can you summarize why ?
Precisely. They must be able to do a DNS lookup for the information
either as a direct data return or a reference to a secondary storage
service, which absolutely could and probably should be LDAP. To
work in practice I think that it should be possible to get a direct pull
from the DNS so that organizations are not required to deploy an LDAP
directory and all that goes along with it (much as that pains me).
I think other people have pointed out that DNS itself is not suited as
the repository for the certificates.
Since the query starts with only the e-mail address, which contains a
userid and domain, I think it is appropriate to start the lookup in the
DNS. There should be a standard schema to get to the appropriate LDAP
server from the user's e-mail domain. The certificate would then be
looked up from it. The client application could also fall back to a
"default" LDAP server if the DNS query fails to find the appropriate
directory.
"Fishing" in domains as you say would be independent of e-mail client
configuration for the most part (it could just be turned on or off).
Actually, I think that "fishing" is an entirely appropriate thing to do.
I didn't say it wasn't, I just have reservations on how it's done (see
above).
The worst that can happen is that don't find the cert your looking for.
Trust issues MUST be dealt with, but certificate trust chains and
approaches are both well understood.
The best that can happen is that suddenly I can go and find a cert for
joe(_at_)foobar(_dot_)com with a simple DNS query. BEAUTIFUL! Why
wouldn't I want
to do that?
Sounds good, but we have to make sure this is deployable for a lot of
people. I don't really see how it would be.
If LDAP is used to store the certs, perhaps all a domain owner might
have to do would be do add an entry in the DNS, either with a new record
type, or even simpler for quicker deployment, a standard name, eg
pki-public-ldap . This entry could be pointed to some free public
directory if the ISP doesn't want to run it itself.
This does lead very nicely into my second (and quite separate) issue in
this area -- the "trusted ROOT certificate". Julien has provided superp
leading commentary here.
You correctly point out that in most cases the user's domain and cert
issuer domain are disjoint. This is especially true of e-mail users
whose ISP isn't a CA (99.9% of them right now).
Exactly. Why? Because it costs TOO MUCH. The only acceptable cost
for most ISP's is zero because of the volume of users. Cost of
certification is, pure and simple, the primary barrier to the general use
and deployment of S/MIME on the Internet.
I think you have it backwards, cost of certification is way down on the
list of obstacles to mass deployment of S/MIME right now. Let me mention
some other important barriers :
1) the general public is completely unaware that certification even
exists. I think this is the #1 issue by far.
Many companies have been trying to raise awareness for PKI, but none
have succeeded in getting the masses to adopt it yet.
2) the value of certification is low today because there are so few
certified users, and encryption only works between certified people.
This is like being one of the first one to have a telephone.
(Even worse than that, without even having a directory in existence to
find out who else you could communicate with - this is the problem at
stake).
3) S/MIME is too complex to use
I don't believe the first issue can be solved by any specifications or
talk in this group, but several companies will continue to work on it.
Hopefully they will succeed.
The first two issues are related. As more people become aware of
certification and certified, the value of being certified will increase.
I believe the cost of the certification will be much less of an issue
once people realize they are paying for a something useful.
IMO, the certificate dissemination issue remains a major obstacle. Even
if lots of people were certified today, it would still be very hard to
know who they are and communicate with them.
The complexity of S/MIME usability is also something the group has
impact on. The specifications heavily impact the implementation and
usability of S/MIME client software.
The reason for the cost is that the mechanism for establishing root trust
is determined solely by the set of ROOT certificates distributed by the
client vendor -- of all things!. Thus only those organizations that can
afford to pay the client vendor -- of all things! -- to be included in
their "special trusted root certificate club" get to have "trust".
Which
means that you MUST buy certs from one of the club members. Doesn't THAT
just suck. Nice business if you can get it.
Yes, vendors have to ship a certain set of roots. We can't just
automagically trust every self-signed root there is. We ship with about
a hundred roots already though. It is true Netscape has charged in the
past for including it. Microsoft requests that your root goes through an
independent certification process. Either way, the process costs a lot
of money.
You aren't limited to using the roots that are shipped.
You can add your own roots if you want to trust it. All it takes is a
couple of clicks in the client application.
If you don't like your users having to click, you can pull a Mozilla
source tree, and add your very own root certificates and mark them
trusted if you like. It is a simple process and I'll be happy to show
anyone how to do it, as I have been the one checking in the roots to the
official tree. Any ISP could do it. Any CA could do it. Any corporation
could do that.
Regardless, to have this power rest in the hands of the client vendor is
ludicrous. Why should I trust that Microsoft can evaluate the security
and trustworthiness of "Joe's CA Service" to be a valid issuer. I'm not
saying they are unqualified to do so, but I'm a lot more likely to
trust a
self signed "Bank of America" certificate issued on it's own behalf and
obtained from a reliable source, than I am a third party software vendor
or CA Verisign (not that there's anything wrong with either Microsoft or
Verisign :-).
All the client vendors do is provide a default trust domain, which is a
list of well-known root certificates with trust settings. What do you
want them to do ? Ship with no roots at all ? Automatically trust every
single self-signed root under the sun ?
The default trust domain that ships with client software is not static.
Like any other software setting, it can be configured. Any user is free
to add another root and mark it trusted.
If the trust domain was static then you would have a point, but as I see
it, you miss the point.
Period. If we want generalized S/MIME usage throughout the Internet we
need to think of some mechanism that is:
1. Easy to deploy. The track record for the Internet stongly indicates
that this means that there are freeware versions of software that will
support the deployment. This includes both the key management and
publication software and the usage (client) software.
At least we agree it needs to be easy.
2. Free. Those who "own" the vast majoritiy of the user population on
the Internet are ISP's. They have almost no margin and simply cannot
afford to pay for certification. Also (and more importantly IMHO) is the
desired for businesses to touch their customers. These are HUGE volume
relationships in which there are virtually no economically viable ways of
establishing bidirectional trust. A cert price of $0.01 a year is too
much if your customer population is 25 million people (banks, utilities,
etc.)
The price figure you cite is absurdly low. Do you really, seriously
think $250,000 to enable secure services matters much to a company with
25 million customers ? Certainly it wouldn't matter much to a bank,
especially since it would probably reduce certain mailing costs. I'd
guess that even one bulk USPS communication is going to cost more than 1
cent per recipient. I only know one ISP with 25 million customers or
more, and I happen to work for it, but I'm not at liberty to comment
further on the costs.
The bottom line is, running a CA is a service, and it costs money,
probably far, far more than $0.01 per cert per year. Whether an ISP runs
it itself or outsources it, the service is going to cost some money
somewhere
Anyway, I think we are getting quite off-topic here. If people want to
run a loss-leader cert service they are welcome to do so, just as
Thawte/Verisign does. I don't know how much relevance this has to the
mailing list. Or do you want to codify the prices of certificates into
the RFCs ?
I can then lookup certs based on mail address (duh!), where the mail
domain source is trusted because of DNS-SEC. This trust relationship
could be either:
implicit -- the issuer domain location is trusted therefore any keys
published there are trusted,
explict -- the issuer provides a root signing key which is in turn signed
by their DNS-SEC key.
What you are proposing is a new policy to automatically trust the
certificate because of the security of the channel it traveled through.
But there has to be some prior trust somehow for the channel itself. I'm
not familiar with DNS-SEC. Does it involve SSL/TLS in any way ? If so
there would have to be prior trust on the DNS server certificate too.
All in all, I think the implicit trust is very dangerous. It is one
thing to accept information through that channel while it is open, but
to continue to use it after it is closed, by automatically trusting the
certificate that was transferred, is another.
You may argue that it is better than nothing, however, a false sense of
security may be worse than knowledge of the lack of security.
Well, even though I would love it if it was LDAP, it isn't going to
happen. DNS is the only game in town for global directory service.
I don't see why the lookup has to be a 1-part lookup. It could - and
probably should, given the size of the problem - take more than one step.
--
I am the dog in dogfood