Re: Re (subtopic): certificate issuance and trust

jpierre@netscape.com (Julien Pierre) Tue, 19 August 2003 00:24 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10294 for <smime-archive@lists.ietf.org>; Mon, 18 Aug 2003 20:24:29 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7INmAqt032315 for <ietf-smime-bks@above.proper.com>; Mon, 18 Aug 2003 16:48:10 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7INmAMG032314 for ietf-smime-bks; Mon, 18 Aug 2003 16:48:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7INm9qt032305 for <ietf-smime@imc.org>; Mon, 18 Aug 2003 16:48:09 -0700 (PDT) (envelope-from jpierre@netscape.com)
Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7INlt309319 for <ietf-smime@imc.org>; Mon, 18 Aug 2003 16:47:55 -0700 (PDT)
Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJUA3I01.G0K; Mon, 18 Aug 2003 16:47:42 -0700
Date: Mon, 18 Aug 2003 16:49:01 -0700
From: jpierre@netscape.com
Subject: Re: Re (subtopic): certificate issuance and trust
To: Steve Hole <steve.hole@messagingdirect.com>
cc: ietf-smime@imc.org
In-Reply-To: <EXECMAIL.20030818101458.A1101@kepler.esys.ca>
Message-ID: <3F4165ED.7@netscape.com>
References: <3F3DA098.1040008@netscape.com> <3F3C4C43.6010205@netscape.com> <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> <EXECMAIL.20030814103028.E@kepler.messagingdirect.com> <EXECMAIL.20030815124859.C1437@kepler.esys.ca> <EXECMAIL.20030818101458.A1101@kepler.esys.ca>
X-Mailer: AOL Communicator (20030811Trnk.1 Win)
Organization: Netscape
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="------------ms010704000904080802040505"
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

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