JDK-4447075 : Sun's JSSE Implementation should use JCE
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 1.0.2
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_2000
  • CPU: generic,x86
  • Submitted: 2001-04-18
  • Updated: 2002-04-09
  • Resolved: 2001-09-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.0 beta3Fixed
Related Reports
Relates :  
JDK-4632653 - Finish crypto reworking - Tighter JSSE/JCE integration
Description

Name: krC82822			Date: 04/18/2001


java version "1.3.0_02"
Java(TM) 2 Runtime Environment, Standard Edition (build
Java HotSpot(TM) Client VM (build 1.3.0_02, mixed mode)

The current version of the JSSE API (1.0.2) cannot easily be used by 3rd
parties. The reference implementation does not support the use of alternative
JCE crypto providers, so it's not possible to use it with a smart card based
application.

If you want to replace the crypto provider, you have to reimplement the whole
SSLSocket stuff including all required SSL protocol versions.
Since most of the methods and interfaces used for the communication between
SSLContext, SSLSocket and the SocketFactory are protected on package level it
is hardly possible to use the existing design in the reimplementation.

Even worse, due to restrictions of the global (non-US) version of JSSE, it is
not even possible to replace the reference implementation completely with a new
3rd party JSSE provider, because the Default-SSLSocketFactory cannot be changed
in this version.

In other words; the current version is only usable with the unchanged reference
implementation, which is not the idea, as our own documentation confirms.
I read about plans to integrate the JSSE API into JCE 1.3 which is in my
opinion a good chance to define some classes (TrustManager, KeyManager,
SSLContext) of the reference implementation as standard api and to provide a
way to replace the JCE provider.
(Review ID: 120928) 
======================================================================

Name: krC82822			Date: 08/07/2001


java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

I have a provider in which i have an implementation of
MD5WITHRSA,MD2WITHRSA,SHA1WITHRSA algorithms. I have installed my provider as
the first provider dynamically.  My problem is that JSSE doesnt uses my
signature implementations during the SSL handshake. I think my provider
installation is ok because when i test by Signature.getInstance("MD5WITHRSA"),
my own implementation is returning. I am struck up with this..Pls help
(Review ID: 126868)
======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta3 FIXED IN: merlin-beta3 INTEGRATED IN: merlin-beta3
02-09-2004
WORK AROUND Name: krC82822 Date: 04/18/2001 No work around, but to use the unchanged reference implementation. (Which is not possible if you want to use smart card based encryption.) ======================================================================
02-09-2004
EVALUATION JCE is the Java Cryptography Extension, and is currently an unbundled product, much like JSSE. However, it will be integrated into merlin (JDK 1.4) due out in late 2001. Our plan is to have JSSE use the JCE framework for it's cryptography. Due to a number of issues involving export restrictions, we haven't been able to let the JSSE use the JCE yet. However, many of those restrictions are now becoming less of a concern, and the JSSE only has a few more obstacles before it can call the JCE. The decisions for merlin's cryptography story have been changing on an almost daily basis. I don't think a redesign of the JSSE API is necessary, but rather the Sun implementation needs to be reworked to take advantage of the JCE. Let us know if this is unacceptable to the customer. I would like to change the bug synopsis to Sun's JSSE Implementation should use JCE bradford.wetmore@eng 2001-04-20 The original bug synopsis was: redesign JSSE API to allow third party crypto providers bradford.wetmore@eng 2001-05-21 Andreas, please see Jeff Nisewanger regarding his ideas for doing this. bradford.wetmore@eng 2001-07-30 JCE providers can now be used for all operations. In addition to MessageDigests, Certificates, etc. which were already using JCA/JCE previously, now RSA, DES, Triple DES, RC4, and RawDSA make use of JCA/JCE providers. The providers must have a higher priority than the JSSE provider, otherwise the JSSE internal implementation are used. ###@###.### 2001-09-17
17-09-2001