From: Christopher Allen <ChristopherA@consensus.com>
Date: Tue, 26 Sep 95 06:00:33 PDT
To: Jeff Weinstein <jsw@netscape.com>
Subject: Re: Please send me SSL problems...
Message-ID: <v0213050fac8d26c8eab1@[157.22.240.12]>
MIME-Version: 1.0
Content-Type: text/plain


At 3:04 AM 9/20/95, Jeff Weinstein wrote:
>  I'd just like to let all cypherpunks know that I'm really interested in
>getting any feedback you might have about security problems with Netscape
>products.  I'm particularly interested in bugs in the our implementation
>of SSL, and problems in the protocol that are not addressed in SSL 3.0.
>
>  We have been collecting comments on SSL 3.0, and have started incorporating
>that feedback into our spec.  Please don't assume that our lack of response
>means that we are ignoring your comments.  Between Navigator 2.0 and
>things like the SSL challenge and the RNG fire drill, we just have not had
>the time to get a new rev of the spec out.  Hopefully soon...

As you may know, Jonathan, who is an active member this list, has already
written about Consensus' intention to continue to upgrade RSAREF. We'd like
to help make sure that RSAREF stays in sync with SSLREF as we upgrade it.
For instance, the next major release of RSAREF will be encrypting the
private key (which now has to be done outside of RSAREF.)

One area in particular we could use some feedback on from you:

Currently SSLREF makes 4 calls that are not in the published program
interface of RSAREF. These calls are DES_CBCInit, DES_CBCUpdate,
RSAPublicEncrypt, RSAPrivateEncrypt. With your license with RSA for RSAREF
you are allowed to go under the published interface by using the DES
routines only for securing the channel, and the RSA routines are limited to
endpoint authentication only.

From what I've heard, SSLREF 3.0 may go beyond those limits, requiring
SSLREF 3.0 developers only to use RSA's BSAFE rather than the less
expensive (or at least, no up-front fee) RSAREF.

What Consensus Development would like to do is extend the RSAREF API such
that RSA's concerns as regards direct access to those routines is taken
care of, and can be called by non-PEM/non-Mail applications such as SSLREF.
We need to extend the API for PGP, so ideally anything new we add to the
API should be general purpose as possible, yet also deal with RSA's issues.

BTW, to explain RSA's issues regarding the RSAREF API: Consensus is
contractually required to get prior approval before licensing RSAREF for
any program that goes underneath the published API. This allows RSA to make
sure that these routines are not used in patented ways that RSA does not
have rights to. In designing new API and getting them to sign off on the
new API allows us to offer licenses to anyone without getting RSA's prior
approval.

------------------------------------------------------------------------
..Christopher Allen                  Consensus Development Corporation..
..<ChristopherA@consensus.com>                 1563 Solano Avenue #355..
..                                             Berkeley, CA 94707-2116..
..<http://www.consensus.com/>             o510/559-1500  f510/559-1505..