Re: Java security support questions

David Brownell - JavaSoft (db@doppio)
Sun, 23 Feb 1997 23:11:28 -0800

Date: Sun, 23 Feb 1997 23:11:28 -0800
From: db@doppio (David Brownell - JavaSoft)
Message-Id: <199702240711.XAA26732@argon.eng.sun.com>
To: java-security@java, mkirk@cisco.com
Subject: Re: Java security support questions

> From mkirk@cisco.com Thu Feb 20 15:16:46 1997
> From: Michael Kirk <mkirk@cisco.com>
> Subject: Java security support questions
> To: java-security@java
> Date: Fri, 21 Feb 97 10:13:03 EST
>
> Hi,
>
> I am currently involved in a project to develop Java applets which will
> make SSL (or TLS) connections. I would like to support the popular
> cipher technologies (eg DES encryption). Clearly I'd prefer for the
> support to be part of Java rather than having to write it myself.

The way it stands today, most security managers will let you do
this if you do it at the level of "https" URLs (rather than the
more widespread "http" URLs). For example, Navigator and HotJava
let you use "https" URLs in the appropriate ways.

I'm not prepared to answer whether this will will be "part of [the
standard] Java [API set]" in the future. It'd make lots of sense,
though, particularly with TLS. In fact, the topic has come up more
than once ... :-)

> I suspect this may happen, but can you give me some idea if this is the
> case, and if so when it would be likely. In addition - if Sun creates
> classes to do all these things, is it guaranteed that they will be
> available in the most prevalent Java environments (i.e. specifically in
> Netscape Navigator, and MS IE) ?

Licencees support the standard Java (tm) APIs, or they lose the ability
to use the relevant trademarks. If SSL/TLS support were a "standard
Java API" ... draw your own conclusion.

However, we've not yet focussed on the goal of making our current SSL/TLS
API become such a standard. First things first: get a solid proposal in
hand (known to support a Pure Java implementation), then negotiate with
partners. I've gotten reasonable initial feedback from some such partners
re our current API, but we've not attempted to get closure on this issue.

- David Brownell

> regards,
> Michael Kirk
>