Re: Re (subtopic): certificate issuance and trust

Steve,

Steve Hole wrote on 08/15/2003, 12:48:


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 :-)


I would also have taken most of the discussion offline already due to 
the direction it is going if there hadn't been many people expressing 
their interest in the topics.

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>


No need to apologize. Likewise I focused mostly on the first usage due 
to the fact that I work for an ISP. However I believe the two uses very 
often intersect. Consumers want to make secure electronic communications 
with businesses (I know I do), which they can't do by e-mail today. 
S/MIME certification allows both.

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.


The complexity was my third one on the list - how S/MIME is difficult to 
use . That included the enrollment process.  I completely agree it is 
very daunting. Actually I have gotten my mother running on S/MIME so I 
know what you are talking about when you mention complexity of 
enrollment. I got her running with Thawte and it was quite long to 
enroll. But there is no reason that it has to be that way - it entirely 
depends on the CA.

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.


I'm not sure I understand why the trust is less of a problem for 
encryption certs than signing certs.
If you want to receive encrypted communications, you need to create an 
encryption key and cert. And you need to make the other party aware of 
it. Typically in S/MIME today this transfer of the public encryption 
cert is done by ... signing an e-mail. Which requires you to have a 
signing cert...
Otherwise the user could also publish the encryption cert to LDAP.
Still there would need to be some authentication at that time.

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.


What are the advantages of these pseudo-security products ?

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.


While we don't have any consensus yet on the technical direction, I 
would certainly be willing to participate in writing a draft that would 
make recommendations on additional ways to distribute S/MIME 
certificates. Of course the actual deployment of a global directory is a 
problem, but perhaps by having this draft written by people involved in 
companies potentially interested in using/running it we will end up 
writing a deployable proposal.

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!


Yes, that's what I meant. Enrollment is part of the usage of S/MIME.
I had to sit with my mother last year to get her to sign up, and I 
talked to her at length at international rates for the recent renewal.

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.


Agreed.

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.


I wish I had the answer to that one.

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 :-)


Yes, I know the feeling, I got the same reaction from my family members, 
which is why I got many of them to enroll with the freemail Thawte CA 
instead.

However the service doesn't have to be directly paid for, or all at 
once. It can be bundled by the ISP with her account. Even if it wasn't 
bundled with every account, the one-time $20 might be only a $1.66 
option/month extra, which is the same price, but suddenly doesn't look 
so bad. Especially if that $1.66 buys you more than just the ability to 
communicate with family members, but also with businesses (ie. banks).

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.


Still, a corporate organization can run its own CA which doesn't have to 
be a root CA.

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.


I think it cannot ever entirely be removed from the client, because you 
need to start with some trust, but it could be aggregated.
Before this can be dynamically controlled however, the very notion of 
what a trust domain is needs to be defined and standardized. Then we can 
define means to transfer it, through existing protocols hopefully.

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.


My huge bank doesn't have to run a root, my huge bank can run a CA and 
get it signed by one of the root CAs. Then it doesn't need to deploy a 
root to every desktop.

If it insists on running a root, there is going to be at least one 
config change to make it happen. Right now I think it is as simple as 
clicking on a URL and accepting a dialog. I don't know how much simpler 
one can make it.

Yes, a means to distribute the trust domain (see above) would help, but 
one would still need to configure the software to use the distribution 
channel - whatever it would be (HTTP, LDAP ...). I don't see how this 
would be simpler than the click and confirmation of the dialog.
The only advantage is that you might only need to enable that trust 
domain service once, and several organizations could publish their root 
to it. You could imagine for example a consortium of financial 
institutions ... Of course the consortium could just have one root and 
bear its cost, and issue one CA for each institution.
FYI, I believe Microsoft might already update roots when you do a 
windows update, but of course that's a proprietary solution, and you 
still have the upfront cost of getting certified when you create your root.

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.


No, it is $250,000 .

You need to go have a look at who I work for :-)


The name doesn't ring a bell, but I will check.

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.


First class stamps are up to 37 cents last time I checked. I don't know 
what the bulk rate is, but using your (unrealistic) proposed cost of 1 
cert per cert, the investment would pay for itself at the first paper 
communication saved even if only 3 percent of the bank customers ever 
used their cert. Of course, it's up to the banks to decide what's 
beneficial to them, but if something is going to save them so much 
money, the bank has responsibility to their shareholders to look into 
it. I don't have any more to add on this topic.

  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.


Someone has to do it right first. Competitors will follow. Same thing 
happened with online account access - not everybody offered SSL. Lots of 
banks erred in offering proprietary software solutions for a while. It 
sorted itself out. We are just at an earlier stage in the process.

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.


Even if that service existed, it would still need some kind of client 
configuration to point to that one place.

-- 
I am the dog in dogfood

smime.p7s
Description: S/MIME Cryptographic Signature