Eric Rescorla wrote: > > Ian Grigg <[EMAIL PROTECTED]> writes: > > > Eric Rescorla wrote: > > ... > > > > The other thing to be aware of is that ecommerce itself > > > > is being stinted badly by the server and browser limits. > > > > There's little doubt that because servers and browsers > > > > made poorly contrived decisions on certificates, they > > > > increased the overall risks to the net by reducing the > > > > deployment, and probably reduced the revenue flow for > > > > certificate providers by a factor of 2-5. > > > I doubt that. Do you have any data to support this claim? > > > > Sure. SSH. > That's not data, it's an anecdote--and not a very supportive one > at that. As far as I know, there isn't actually more total > SSH deployment than SSL, so you've got to do some kind of > adjustment for the total potential size of the market, which > is a notoriously tricky calculation.
It's more than an anecdote. If I quote from your slides, SSH has achieved an almost total domination of where it can be deployed. Wherever there are Unix servers, we suspect the domination of SSH. (I haven't got a good figure on that. Some stats have been done Neils Provos and Peter Honeyman in a paper, but I can't interpret the results sufficiently to show SSH server distribution, nor penetration [1]. It's now a hot topic, so I believe the figures will become available in time.) > Do you have any actual > data or did you just pull 2-5 out of the air? There is a middle ground between data and the air, which is analysis. I've been meaning to write it up, but I'm working on the SSL threat model right now. > > It's about take up models. HTTPS' > > model of take-up is almost deliberately designed > > to reduce take-up. It uses a double interlocking > > enforcement on purchase of a certificate. Because > > both the browser and server insist on the cert > > being correct and CA-signed and present, it places > > a barrier of size X in front of users. > I don't know where you got the idea that the server insists on cert > correctness. Neither ApacheSSL nor mod_SSL does. I take the following approach here. I think that for Apache to promote the interests of the users, it should configure automatically to run SSL, and automatically generate a self-signed cert on install (unless there is one there already). I admit I haven't looked to see whether that is reasonable or possible, but I gather it does neither of those things, and it certainly doesn't make doing self- signed certs so easy. Oh, and Apache does lead one astray by calling the self-signed cert a "snake-oil" cert. This misleads the users into thinking there is something wrong with a self-signed cert. I'm not sure how easy that is to correct. > > Instead, if there were two barriers, each of half-X, > > being the setup of the SSL server (a properly set > > up browser would have no barrier to using crypto), > > and the upgrade to a CA-signed cert, then many more > > users would clear the hurdles, one after the other. > Maybe, maybe not. You've never heard of price inelasticity? > > The fact of the matter is that we have no real idea how > elastic the demand for certs is, and we won't until someone > does some real econometrics on the topic. Unless you've > done that, you're just speculating. The reason we have no idea how elastic the demand for certs is, is because a) we've never tried it, and b) we've not looked at the data that exists. (Yes, those reasons are contradictory. That's part of the world that we want to change.) It's nothing to do with whether the ivory tower brigade does some econowhatsists on their models and then speculates as to what this all means. Have a look at the data that is available [2]. You will see elasticity. Have a look at the history of a little company called Thawte. There, you will see how elasticity contributed to several hundred millions of buyout money. Mark S prays to the god of elasticity every night. Check out the Utah digsig model. If you can see a better proof of cert elasticity, I'd like to know about it. iang [1] http://www.citi.umich.edu/u/provos/ssh/ http://www.citi.umich.edu/techreports/reports/citi-tr-01-13.pdf [2] http://www.securityspace.com/ http://www.securityspace.com/s_survey/sdata/200308/certca.html --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]