From: kipp@warp.mcom.com (Kipp E.B. Hickman)
Date: Thu, 9 Feb 95 10:04:03 PST
To: cypherpunks@toad.com
Subject: Re: skronk
In-Reply-To: <199502081852.KAA01719@gwarn.versant.com>
Message-ID: <3hdl7u$35a@flop.mcom.com>
MIME-Version: 1.0
Content-Type: text/plain



In article <199502082025.MAA00565@jobe.shell.portal.com>, hfinney@shell.portal.com writes:
> >THUS SPAKE "Kipp E.B. Hickman" <kipp@warp.mcom.com>:
> ># It does what you are trying to accomplish (I think), and it is already deployed
> ># in production code (the Netscape client and server products). In addition, we
> ># announced this week a free (for non-commerical use) reference implementation.
> ># The code will be out on the net as soon as the lawyers are happy :-)
> 
> When we last left this story, only certificates from a few (one?)
> signatory authorities were going to be accepted by Netscape clients.
> Would this mean that competitors offering Netscape servers would have to
> go to Netscape to get their keys signed in order to interoperate with
> existing Netscape clients?  I think this is too limiting.

The SSL protocol doesn't define how certificates are truly validated:
It does indicate what operations should be performed, but it doesn't
say how you go about getting the data to perform the operations.

Because there isn't a solid public-key infrastructure in place today,
the Netscape Navigator product (1.0 and the up and coming 1.1) only
support a few well known CA's that are built into the client
(ick). The CA's that are supported today are:

    C=US, OU=Test CA, O=Netscape Communications Corp.
    C=US, O=RSA Data Security, Inc., OU=Commercial Certification Authority
    C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority
    C=US, O=MCI, OU=internetMCI, OU=MALL

So you see, you don't have to come to Netscape Communications Corp. to
get a certificate. Of course, this list is kinda short, etc. etc. etc.
We have IPRA's certificate too, but because IPRA has no financial
backbone, we have not included it in the Navigator product.

> People should be able to choose their own key signers.  This should be a
> configuration option.  It should not be compiled into the client!  That
> hurts your own flexibility as well as interfering with interoperatbiliy.

Of course this sucks. We plan on fixing this in a future release of
the navigator (after the 1.1 release).

> Can I use this reference implementation and set up a SSL-compatible
> service today, or do I have to go to you and/or everyone's friends at RSA
> and get a signature first?  As long as it is the latter I think that SSL
> is not going to be able to be a well-established standard.  People are
> going to resent having to register with the authorities in order to set
> up a secure web page.

SSL requires server operators to be certified so that the end users
(e.g. consumers) can have some faith in the data they are receiving,
and believe in the privacy of the communications. IMHO, before you can
get the consumers to truly believe, you must have a technically sound
solution.

It would be possible to modify the protocol to allow a non-certified
server to operate. However, this sort of thing is subject to the
man-in-the-middle attack. If we allow this sort of attack, and it
turns out to be the only easy way for an attack to occur, guess what
will happen?

---------------------------------------------------------------------
Kipp E.B. Hickman          Netscape Communications Corp.
kipp@netscape.com          http://home.mcom.com/people/kipp/index.html