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
- dissemination of public encryption certificates Julien Pierre
- RE: dissemination of public encryption certificat… Blake Ramsdell
- RE: dissemination of public encryption certificat… Alberti Antoine
- Re: dissemination of public encryption certificat… Alberto Cozer
- RE: dissemination of public encryption certificat… Hallam-Baker, Phillip
- Re: dissemination of public encryption certificat… Simon Josefsson
- Re: dissemination of public encryption certificat… Anders Rundgren
- RE: dissemination of public encryption certificat… Julien Pierre
- RE: dissemination of public encryption certificat… Julien Pierre
- Re: dissemination of public encryption certificat… Julien Pierre
- Re: dissemination of public encryption certificat… Julien Pierre
- Re: dissemination of public encryption certificat… Steve Hole
- RE: dissemination of public encryption certificat… Hallam-Baker, Phillip
- Re: dissemination of public encryption certificat… Michael Helm
- RE: dissemination of public encryption certificat… Hallam-Baker, Phillip
- RE: dissemination of public encryption certificat… Blake Ramsdell
- RE: dissemination of public encryption certificat… Julien Pierre
- RE: dissemination of public encryption certificat… Julien Pierre
- Re: dissemination of public encryption certificat… Julien Pierre
- RE: dissemination of public encryption certificat… Paul Hoffman / IMC
- Re: dissemination of public encryption certificat… Anders Rundgren
- Re (subtopic): LDAP certificate distribution Steve Hole
- Re (subtopic): certificate issuance and trust Steve Hole
- Re: dissemination of public encryption certificat… Julien Pierre
- Re: Re (subtopic): certificate issuance and trust Julien Pierre
- Re: Re (subtopic): LDAP certificate distribution Vadim Fedukovich
- Re: Re (subtopic): certificate issuance and trust Steve Hole
- Re: Re (subtopic): certificate issuance and trust Julien Pierre
- Re (subtopic): Four corner model Anders Rundgren
- Re: dissemination of public encryption certificat… Peter Gutmann