# Bundling parts of JCE for export.

J. Kelly Johnson (kellyj@ricochet.net)
Mon, 25 Aug 1997 15:04:19 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Li Gong: "Re: Bundling parts of JCE for export."
- Previous message: Yosihisa Matsuura: "Question about the SecurityManager"
- Next in thread: Li Gong: "Re: Bundling parts of JCE for export."

    Date: Mon, 25 Aug 1997 15:04:19 -0700

    From: "J. Kelly Johnson" <kellyj@ricochet.net>

    To: Java Security Team <java-security@web2.javasoft.com>

    Subject: Bundling parts of JCE for export.

Marianne:

I am the tech lead for a significant distributed object Java project
at IBM and the issue of supporting foreign clients of our system using
weak cryptography has become very important. A few weeks ago I
posted the message copied below. I know that you can't
answer all questions posted here, but perhaps you could suggest
a route for us to follow up on this issue (support fees would not
be a problem).

Thanks for your time,

J. Kelly Johnson
AppletVisions Inc.

==================== Previous Post ===================================

You mentioned in a previous response:

> Encryption/decryption is
> controlled by the US govt, meaning that we can't export encryption
> APIs. Companies can export products that have encyption bundled
> into them as part of the product, as long as the crypto APIs aren't
> exposed, and the bundled crypto is the so-called "weak" crypto.

Does this imply that one could "bundle" some JCE classes in an
exported java application which uses those classes (only using short
keys -
and possibly with modified JCE classes to prevent longer keys)
w/o violating the rules as long as the application does not "expose" the
JCE APIs to the end user? Or is it the nature of java applications
that the APIs associated with all classes contained therein are
considered "exposed", and only compiled traditional language
programs (like Netscape) using compiled encryption libraries (SSL) can
do
this? If so, this seems to relegate Java applications to an inferior
position as compared with traditional compiled applications.

It is crucial to our project that we at least have weak crypto
capability to protect the communications between the client part of
our distributed Java application running on a foreign system and
its associated server-side remote objects running on our (US) system.
Is
there any other way to accomplish this without being forced to run
as an applet via an SSL enabled browser using inefficient http/cgi
communications?

Your thoughts are much appreciated!

J. Kelly Johnson
AppletVisions Inc.

- Next message: Li Gong: "Re: Bundling parts of JCE for export."
- Previous message: Yosihisa Matsuura: "Question about the SecurityManager"
- Next in thread: Li Gong: "Re: Bundling parts of JCE for export."