On Fri, 15 Aug 2003 20:10:16 -0700 Julien Pierre
<jpierre(_at_)netscape(_dot_)com>
wrote:
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.
If you either (1) engage the desktop keypair generation CSR issuance or
(2) generate a keypair and deliver it via PKcS12 at enrollment time, then
you can issue data encipherment only key-usage keys that are only used for
encryption. The keys can be self signed and really are only ever used to
decrypt data sent from the document issuer and cannot be used for signing.
By doing this, you avoid all root signing issues and all of the extremely
nasty UI that prevents people from enrolling and generates calls to
customer service. The certificates need to be validated before we use
them to encrypt, but that is all local security policy and we do a lot of
stuff beyond normal certificate validation to make sure our certs are
valid. Once encrypted, the user just needs to have the private key to
decrypt and the cert is really only used to keep the cert store happy on
the desktop.
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.
> 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 ?
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.
This sucks!
> 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).
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.
> 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.
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.
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.
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".
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.
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.
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.
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".
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.
> > 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 .
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). 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.
Cheers.
---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:holes(_at_)ACIWorldwide(_dot_)com>
Phone: 780-424-4922