JDK-4532506 : Serializing KeyPair on one VM (Sun) then Deserializing on another (IBM) fails
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 1.3.1,6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2001-11-28
  • Updated: 2017-05-16
  • Resolved: 2003-09-11
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
5.0 tigerFixed
Related Reports
Duplicate :  
JDK-6536046 - Serialization and javax.security interface classes (e.g. PublicKey)
Relates :  
JDK-4833034 - Obfuscation is changing variable names for serialization
Description

Name: jl125535			Date: 11/28/2001


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



I have a service based application which downloads code to access the application 
remotely. If the client VM is say IBM but the VM which runs the application is Sun then 
I cannot send a KeyPair (or any object which contains PublicKey,PrivateKey) down a 
socket using Serialization.

Because KeyPair uses the default serialization then when it comes to serialize the 
public and private components of the pair (which are only interfaces PublicKey & PrivateKey) 
then the real objects are serialized. On a Sun VM this is com.sun.xxx but on an IBM this 
is com.ibm.xxx.

If the application uses some rpc type communication then any remote interfaces 
cannot contain any methods which contains these objects in their declaration:

public void verify(PublicKey key) - could not be an rpc method.


There is a work around (described later) but this still means the rpc method has to 
change and really if I use something in any java. packages then I should really expect 
this to work on other VMs (Write once run anywhere?) and I thought this may of been 
the reason for the provider pattern in the security architecture.


public void verify(ManuallyEncodedPublicKey key)

    - manually serializes the key using X.509EncodedKeySpec

This has impact on any serialization of these classes accross multiple providers.
(Review ID: 135083) 
======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b20
14-06-2004
EVALUATION 1. new public serialized key representation: public class java.security.KeyRep { public KeyRep(String type, // "PublicKey|PrivateKey|SecretKey" String algorithm, String encoding, // "X509|PKCS8|RAW" byte[] encoded) { } protected Object readResolve() throws ObjectStreamException { // use KeyFactory to create key } } 2 modify PublicKey/PrivateKey/SecretKey javadocs to state (respectively): A PublicKey should use KeyRep as its serialized form. (don't say anything about encodings - anything is fine) our provider Key classes would writeReplace KeyRep, but also implement readObject so it can deserialize pre-1.5 keys if it gets one (if KeyRep is received, KeyRep's readResolve is used).
11-06-2004
WORK AROUND Name: jl125535 Date: 11/28/2001 CUSTOMER WORKAROUND: This means any distributed application which uses the java.security.PublicKey and java.security.PrivateKey has to serialize the keys manually using some encoding like X.509 and PCKS#8 to ensure that whatever provider is set for the security keys doesn't store the private & public keys as the implementation objects. ======================================================================
11-06-2004