I broke the reply into to parts because they really are quite separate
issues. This topic deals primarily with the issuance of certificates and
trust management in deployed S/MIME clients. I debated taking it
offline, but I think that it is useful discussion from a usage point of
view. It has little technical merit on a primarily technical forum, but
it has overall import for S/MIME -- I hope :-)
On Thu, 14 Aug 2003 19:58:11 -0700 Julien Pierre
<jpierre(_at_)netscape(_dot_)com>
wrote:
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.
OK. Before I go on, I will state that I agree with both of these
assertions on an individual basis. The issue is really how many of these
things work in combination to stall or make S/MIME usage difficult.
I see that we need to talk a bit about the usage models that are evolving
on the Internet. There are at least two with variations:
1. Interpersonal secure mail. This is Mom exchanging secure email with
Aunt Jane on the other side of the country.
2. Organizational communications. This is the business to consumer or
organization to partipant communications (ie. my bank wanting to send me
statements and me wanting to complain to my bank).
<apology>
Because I am so focused on usage model 2 these days I tend to forget about
usage model 1. My apologies. Conversely, I suspect that very little
thought has gone into usage model 2 as it is an entirely new thing for
business to be doing on the Internet.
</apology>
So what? Your assertions and the priority you assign them are spot on
for usage model 1. I would still add both cost and complexity of
certification to this model. For Mom to sign up to get a cert is
actually pretty daunting from a user interface point of view. We and our
customers have done lots of user tests and it is a problem.
My assertion that cost is a big deal is very applicable to usage model 2.
In this case organizations want to certify their consumers for secure
document receipt and (possibly) reply. Outbound is fairly easy -- just
issue an encryption only cert to the user on enrollment. No trust issues
and it is reasonably easy to get to the user's desktop. The problem
comes when you want bidirectional communication and are therefore issuing
signing certs. The cost of doing this for millions of customers is so
high using the existing certification model (because of root trust
requirements) that to use S/MIME becomes impractical or forces alternative
solutions.
There are a series of companies that provide "e-mail encryption" using
proprietary formats and Javascript symetric decryptors that completely
bypass S/MIME altogether. And people buy it! BIG organizations buy it.
It's depressing. And when talking about S/MIME it has to be concern to
this group and people who implement S/MIME clients.
(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).
Correct. This means that interpersonal secure email usage is
impractical because there is no way to obtain necessary security
information for an arbitrary recipient. This is the original stated
problem and we all agree that it is a major, if not the major barrier.
I think that we have some good concensus building on that and maybe there
are some actions that we can now take to try to resolve the issue.
3) S/MIME is too complex to use
S/MIME isn't so complicated (at least our user testing doesn't indicate
that). We get very few usage calls back to customer support.
Certification is certainly complicated. Even the easiest of the
commercial (Verisign) CA's are quite daunting to the average user. This is
an implementation issue that needs some work. This accounts for better
than 95% of our TOTAL service calls. Ouch!
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 only way to solve it (I think) is to have organizations initiate
certificate issuance. That is, ISP's need to offer to do this as part of
their enrollment.
Certificate awareness is very high in my usage model 2 because either Joe
Customer wants to get e-documents from Sam Business or Sam Business wants
Joe Customer to get e-documents. Either way, there is explicit
communication that initiates certification (in all the various ways that
can be done).
So it is a question of how do we initiate certification? More
importantly how do we get ISP's (or a proxy third party) to engage users
in the certification process.
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.
No it won't :-) Will your Mom pay to be certified? I know for a fact
mine won't because I tried to get her to get a Verisign cert and when she
found out it was $20, that terminated that conversation quickly :-)
It will improve yes, but you won't get anywhere near universal uptake.
... some stuff skipped ...
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.
You are right. I knew when I was writing that part that I was going to
get into trouble :-).
First of all, this problem really is a usage model 2 issue. An
organization wants to certify a very large number of users. It really
doesn't apply to usage model 1, for which most of the existing S/MIME
clients are targeted.
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.
All of the above is correct. I'm saying two things:
1. It would be very nice if there is some way that the trust domain could
be removed from client configuration to a centralized service. This is
simply good engineering and allows for dynamic control over what is
trusted and what is not.
2. Modifying desktop settings to support security policy and certificate
issuance is a non-starter for usage model 2. It's the old adage --
people want security but they don't want to have to do anything to get it.
I'll give you an example that might help. If My Huge Bank wanted to
issue certificates to their users to establish a secure email community of
trust, then they have two choices: acquire certificates from one of the
CA's that is already in the "trusted root" category or try to issue
self-signed certificates and become a trusted root. Cost is a big barrier
in the first option. Deployment complexity (and some cost) is a barrier
for option 2. Because a new root certificate has to be downloaded to
every desktop you've got a deployment latency problem. Because it costs
(in some non-insubstantial set of S/MIME implementations) to get a
registered root certificate, the costs of this are not insubstantial
either.
If the cost that an organization like My Huge Bank will bear to roll out a
new service is $1M - $500K you can see that the cost of deployment for an
S/MIME solution is severly compromised by the costs of certification.
Companies and solutions like Tumbleweed exist that provide alternatives to
S/MIME simply because of this fact.
If we could arrange things to avoid the cost and provide zero deployment
latency, that would greatly enhance usage model 2 scenarios and make life
difficult for non-standard email security solutions.
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.
First of all, $0.01 per cert for 25M customers is $2.5M annually.
You need to go have a look at who I work for :-)
The example that I give above is by far the rule. The costs that even a
large bank with 25M consumers will bear for *any* Internet application is
quite low at this point. Most of that has to do with the series of
disappointing Internet applications and middleware that were invested in
over the years has seriously damaged their trust in real return on
investment in Internet applications.
The *only* reason that we can sell secure document delivery systems to our
customers with S/MIME based security is that we do one-way encryption only
solutions which obviates the need for signing certs and trust. Even with
that, many of our customers find the simple certification issuance that we
do (two dialogs and a single page turn) too much and want to use password
based encryption instead. We have been forced to write an S/MIME viewer
application that supports the S/MIME shared secret profile because very
few of the shipping clients support it yet.
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 ?
Agreed, we can take the remainder of this conversation off line.
However, it is important to note that the cost of running a your own CA
today is largely a matter of the licensing costs of running the CA
software. There are operational costs, but those costs can and should be
part of the cost of operating the application the uses S/MIME. We do NOT
charge for certificate issuance in our product. We charge for documents
delivered. There is a direct and easy comparison for any usage model 2
document issuer to compare the cost of paper mail to secure email. If we
had the ability to "Register" a self certifying organization root
certificate in one place (not one for every desktop client) that would be
a huge step forward.
Cheers.
---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:holes(_at_)ACIWorldwide(_dot_)com>
Phone: 780-424-4922