Re (subtopic): certificate issuance and trust

[Steve Hole <[e-mail]>]

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 <[e-mail]> 
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:[e-mail]>
Phone: [phone]