# Re: JDK 1.2, please provide SSL interfaces and "force" :-) browser vendors to provide implementation

David Brownell (David.Brownell@Eng)
Thu, 20 Nov 1997 12:35:44 -0800

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Previous message: Andrew D. Fernandes: "cryptographic service provider"

    Date: Thu, 20 Nov 1997 12:35:44 -0800

    From: David.Brownell@Eng (David Brownell)

    Message-Id: <199711202035.MAA21668@argon.eng.sun.com>

    To: gchung@openhorizon.com, java-security@javasoft.com

    Subject: Re: JDK 1.2, please provide SSL interfaces and "force" :-) browser vendors to provide implementations

George,

JavaSoft has defined the "SSL Standard Extension", and a number of the
major licensees have said they'll use JavaSoft's API for this specific
functionality. That will help achieve the goal you noted.

We've published the APIs now, the main issues I'm aware of are pragmatic
ones like how we should make this software available to broader audiences;
as you may know, it's tough to "force" folk to ship software that has the
sort of export control issues that SSL does. Luckily, SSL is in much
demand; there's lots of "pull" to get this functionality out there. For
example, HotJava Browser 1.1 and the Java Web Server 1.1 both include
this API, as does the next JavaOS release and other JavaSOft software.

My preferred solution is much like what you described: provide a release
of the Java Platform (specifically, JDK and JRE) with which we bundle
binary versions of the SSL software. However, I don't get to make the
decisions about how we bundle or unbundle things, so it's hard to say if
that'll happen!

- Dave

> From gchung@openhorizon.com Wed Nov 19 16:48:15 1997
> From: "George Chung" <gchung@openhorizon.com>
> To: <java-security@javasoft.com>
> Cc: "George Chung" <gchung@openhorizon.com>
> Subject: JDK 1.2, please provide SSL interfaces and "force" :-) browser vendors to provide implementations
> Date: Wed, 19 Nov 1997 13:53:40 -0800
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
>
> Dear Sir/Madam,
> Two requests...
>
> 1. Doesn't it seem reasonable to have the browser vendors who license Java
> provide an implementation of an SSL socket? After all, they expose SSL
> functionality at a high level through URLConnection. Otherwise, if my applet
> needs a client side SSL socket, the applet will have to be packaged with a
> commercial Java SSL package which would add considerably to the size of the
> download. Seeing that one of the hallmarks of Java is security, my humble
> opinion is that security (in this case client side SSL sockets) should be
> easily available to an applet and minimum expense (download time and
> licensing).
>
> 2. Provided that point 1 is a reasonable request, then it would be logical
> for JavaSoft to provide standard SSL interfaces. Why?
>
> If the browser vendors expose SSL functionality by providing a subclass of
> Socket, say SSLSocket, I need a portable way of configuring that SSLSocket
> whether I'm inside a Netscape browser or an IE browser.
>
> In other words I need a portable way of creating certificate chains (if the
> client needs to be authenticated), creating an ordered list of desired
> cipher suites, verifying the certificate chain sent by the server, etc.
>
> Otherwise I have to write a lot of conditional code depending on what
> SSLSocket implementation I'm using.
>
> Am I way off base? What would be the issues (technical and legal) that
> prevent such an environment?
>
> Regards,
> George Chung
> Open Horizon, Inc.
>
>
>

- Previous message: Andrew D. Fernandes: "cryptographic service provider"