From: Alex Strasheim <cp@proust.suba.com>
Date: Sat, 9 Mar 1996 07:46:29 +0800
To: froomkin@law.miami.edu (Michael Froomkin)
Subject: Re: Not a good idea...
In-Reply-To: <Pine.SUN.3.91.960308104119.29952C-100000@viper.law.miami.edu>
Message-ID: <199603081914.NAA02963@proust.suba.com>
MIME-Version: 1.0
Content-Type: text


> Nice try.  Wish my students were that creative.  I don't think it works,
> though, at least when CA's represent that their info is suitable for
> relying parties to use in financial transactions (something Siskel & Ebert
> do not do!).

(Sorry, this ends up rambling way off topic at the end... it turns into a 
rant about preinstalled CAs.)

But when did they make that representation?  Is such a representation
inherent in every CA?  If it is, doesn't that imply that the only reason
for a CA to exist is to provide trust for financial transactions?  It's 
clear (to me, at least) that there are other uses for a CA.

Netscape has represented its products as suitible for commerce, and it
doesn't seem unreasonable to argue that this representation gives
customers and banks an expectation that a certificate from a preinstalled 
CA confers a degree of trustworthiness on the cert holder.

But a CA that doesn't come pre-installed shouldn't be viewed as having
made any implied representations at all.  If a CA controls the
distribution of its key by asserting a copyright, and if it requires
everyone who downloads it to click on a form that says they've read and
understand what a cert from that CA means, then that's what it should 
mean.

Suppose I run a Netscape Commerce server, and I set up a secure forms
processing service.  Anyone can anonymously pay me to set up a perl script
on my SSL server to accept their form data.  My script will take the data,
encrypt it with PGP, and then mail to whatever email address my customer
(the web page owner) has specified. 

Who's liable?  Me, Verisign, or Netscape?  All of us?  

I suspect that if I pass credit card numbers to thieves I'll get in
trouble, but I don't have any assets.

Verisign didn't make any representations directly to the public, and they 
probably followed the procedure they negotiated with Netscape when they 
issued me my cert.

Netscape put together a complicated high-tech system and told the public
(which doesn't understand cryptography) that their system was suitible for
commerce -- it's even in the product's name!  They didn't build in prudent
safeguards to prevent me from running my forms processing service, which
is such a trivial thing to set up that it should have been forseen.  (Q:
I've never gotten a real cert -- do I have to agree to something that
would prohibit my forms processing business?)

(Could a lawyer asking a jury for a judgment against Netscape show them 
the picture of Andressen from the cover of Time, the one where he's 
sitting on a throne, hubris personnified?)

It seems to me that the claims of commerceworthiness, preinstalling CAs,
and the like are going to turn out to be bad for everyone.  

They're bad for Netscape because they exposes them to liability
unneccessarily.  Why should they say their products are suitible for
commerce when they can instead say that they encrypt the traffic using
what are believed to be strong algorithms?  Everyone will make the jump
from that to commerceworthiness on their own.  

What does commerceworthiness mean, anyway?  Transcations up to $1,000? 
$1,000,000?  Remember that SSL web tools are begining to function more and
more as front ends of other kidns of progrms -- there's more at stake here
than credit card numbers typed into forms for consumer purchases.

Preinstalling CAs is great if you want to relieve users of the necessity
of deciding for themselves who they should trust.  You, or a system that
you designed, will make those hard decisions for them.  But it's not so
great if you don't want to be held accountable for almost every single
decision regarding trust on the web.

It's also bad for those of us who want to see crypto widely deployed on
the net.  Solid free code exists, but the cost of licensing the patents
and buying certs is keeping crypto expensive and slowing deployment. 
Preinstalling CAs means that a would be commerce server operator has to
buy a cert or operate from a competitive disadvantage.  It's a significant
cost -- the cert is more expensive than the RSA licence.  It costs as much
as a Fast Track server.  

The patents will go away.  When that happens, the only thing preventing
totally free crypto will be the cost of the certs.  I suspect that
Netscape started thinking about the CA system, they were selling SSL
servers for around $2,000.  A $300 cert isn't such a big thing in those
circumstances -- there's not much of a marginal difference between $2,000
and $2,300.  But now the price of a server is only 15% of that $2,000, and
the price of the cert looks awfully high.  What will it look like when SSL
web servers are free? 

Finally, it's bad for consumers.  Apart from the obvious observation that
the cost of the certs will get passed on to consumers, it's important to
note that it costs money to have someone else decide who you should trust. 
The quality of that decision making affects its cost, and it should be the
marketplace, not a handful of corporate managers, that determines where
the optimum price/quality point is.  Different customers ought to 
be able to make different choices depending on their needs.  

That choice is possible now in an abolute sense, but managing CAs will be
confusing for users, and Netscape's preferential treatment of certain CAs
will clearly hinder open competition among CAs.  It will also tend to
impose an unnatural homogenity on users who have different security needs. 
A guy who never buys anything online but wants to be able to browse web
pages without his ISP knowing what he's looking at has different security
needs from another person who does most of his shopping on the web. 

Security *is* economics, and it's important to keep the floor as low as 
possible.  The current CA system is one of the main things keeping the 
floor higher than it ought to be.