Re: Re (subtopic): certificate issuance and trust

[[e-mail] (Julien Pierre)]

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