Re: Re (subtopic): certificate issuance and trust

[Steve Hole <[e-mail]>]

On Fri, 15 Aug 2003 20:10:16 -0700 Julien Pierre <[e-mail]> 
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:[e-mail]>
Phone: [phone]