Re: Re (subtopic): certificate issuance and trust

Steve

Steve Hole wrote on 08/18/2003, 10:14:

I talk about cost a lot.   The average cost of a call to support is $18,
so it needs to be avoided at all costs (pun intended).

The interfaces provided by IE and/or Netscape provide much simpler,
not so
"in-your-face" UI for cert management when there is no trust involved.


It sounds to me like your grief is not with so much with the current 
trust model and PKI or S/MIME specifications, but with certain vendor 
implementations. I'm afraid that's something you have to work with these 
vendors.

What are the advantages of these pseudo-security products ?


They avoid certification.

They address the 36% of the Internet that doesn't use or have access to
S/MIME software -- primarily AOL, Yahoo!Mail and Hotmail.   If your in a
model 2 scenario you MUST do something useful with those and the solution
is psuedo security.   Interestingly, it seems good enough for most
people,
especially if it avoids calls to service reps.


AOL will be taken care of, eventually. The newest client software (AOL 
Communicator) already supports S/MIME. There are still issues with the 
mail servers unfortunately so it doesn't work today. Encryption works 
through it, but signing doesn't (sigh).

Webmail in general is a problem and cannot be truly taken care of, 
unless the user is willing to trust his ISP with his private key - e.g.. 
by uploading a PKCS12 file ...

Another solution might be some sort of Java applet that would decrypt 
the message. But it would have to know about each webmail provider and 
the layout, so it would be icky.

Perhaps some standard for webmail is the only solution - e.g.. a MIME 
type transmitted over HTTP that would allow the browser to invoke the 
proper S/MIME client.

This sucks!


In general the users don't have only webmail access though, they 
typically have a mailbox from their access ISP which can work with the 
S/MIME clients that already exist today.

Well, I'm not an expert on ISP business models.   Everything I've ever
been told suggests that there is almost no margin in the business model
and additional costs are hard to bear or pass through.   For this you
have
to convince the masses that security is what they want, and I can tell
you
from experience that that is a very difficult thing to do.   And my
experience comes from a business usage perspective where the content
definitely is sensitive in nature -- much more so that most email between
Mom and Aunt Jane.


I'm not an expert on this business model either either, but look at the 
latest AOL ads - "safe broadband", etc. This is certainly an area in 
which consumers are being educated right now, and security is something 
that consumers are getting interested in. I personally think there is 
hope for mass S/MIME deployment in the not so-distant future.

If you can acquire a delegated cert.   We haven't check recently, but 6
months ago we couldn't buy one.    Thawte used to sell them for $100K,
but
since have discontinued because there was no business there.   We should
go check again.   It was the simple and obvious thing to do, but because
there was nobody doing it, the service wasn't offerred by the CA's.


We have had our own chained CA chained with a known public root at 
Netscape for years. We did change issuer a couple times. Our current one 
is GTE. I think previously we used Verisign. I wasn't the one dealing 
with it, and I don't know the cost, but I can tell you that the service 
exists. Since there are about 100 known roots now, you could go to any 
of them and ask about the service. I think I read year's that RSA 
Security was offering that service as well, and it cost less than $100k.

The client would have to have some secure means of "synchronizing" it's
cache to a centralized service.   You get this with Microsoft services by
downloading a cert package from Windows Update.   The problem is that it
only works for Windows products (at least that way) and we need something
that is vendor independent.   The approach seems OK to me as long as
it is
"automatic".


Yes. We need a standard way of distributing root. We also need a way of 
distributing trust, ie. a subscriber model.
It sounds to me like this proposal belongs on the PKIX list, so maybe we 
should move it there.
I don't see the root distribution problem as a major roadblock to 
deployment today since the services for getting chained CAs exists.

Seems logical.   In practice we were unable to make it happen.   We
needed
to go through special negotiation because it wasn't a standard service
offering and there was a serious price issue for the signing cert.


Yes, it may not be a standard service, but if you need it there is far 
more than one issuer to go to these days.

In Netscape, yes.   In others no.   You actually get a Hex dump of the
cert with a message that says something like "Do you trust this
certificate with policy blah blah".   About 45% of the test group stopped
at this point.   Most of our customers simply said "too complex, too
scary".


As I recall IE brings up something similar to Netscape when the root is 
untrusted. What is the "other" software that is so inflexible ? It seems 
to me that you need to take it up with the software vendor.

Yes, I know it should be scary etc.   The problem is that the average
user
just doesn't get it, doesn't want to get it.  It's a barrier to uptake.
For the model 2 usage scenario uptake is everything because the economic
benefit is based on paper suppression and resulting cost reductions.

That's all.


You can't require everybody to move to the S/MIME model at once. Even if 
a small percentage starts using it, the cost of printing and mailing is 
high. If you eliminate things like printed monthly statements, it 
shouldn't take a bank more than a small percentage of users to move to 
S/MIME to recoup its costs or actually profit.

 > First of all, $0.01 per cert for 25M customers is $2.5M annually.

No, it is $250,000 .


Woops ... dislexic on the cost per cert.   The cheapest price we got was
$0.10 (man, I *looked* that at least five times too - senility).


That's still very low, but it's also likely less than the cost of 
printing and sending a single traditional communication.

Anyway,
the numbers weren't randomly chosen.  They were the numbers that we used
in an actual RFP response in which the customer eventually took the
one-way signing + encryption and decided against two-way with
bidirectional signing.   The actual cost was $2.5M per year.

Security costs.  My example was intended to show that, in this
instance at
least, it costs too much even for relatively rich organizations.


I also know there are other financial organizations that spend much more 
on better security, and get more returns out of it. Look at credit card 
issuers starting to use smartcards. They have to bear the cost of the 
hardware in addition to the certs. They have millions of customers too. 
But some are doing it still (Amex). In Europe banks have been using 
smart chips on bank cards for decades. And believe it or not, they have 
been charging each customer to get those bank cards, too. Every bank 
over there is doing it though, because it reduces the transaction costs. 
We are not talking 10 cents per chip. With current generation smartcards 
they could afford to throw in certs for email as an extra and also 
eliminate the paper statements. Many of the issuers already have their 
own public roots to do it.

-- 
I am the dog in dogfood

smime.p7s
Description: S/MIME Cryptographic Signature