IZ47986: INSTANTIATING A CONTENTINFO OBJECT TAKES A LONG TIME FOR CERTAINFILES.
Closed as program error.
IBM JDK 150 SR8A Component: IBM PKCS Problem Description: ==================== Instantiating a ContentInfo object can take a long time for certain files because of poor byte array manipulation within the getIndefSeqSet( ) method of the DerIndefLenConverter class. Example: ContentInfo contentInfo = new ContentInfo(filename, false); JDK affected: 142, 150, 160 JARs affected: ibmpkcs.jar Customer Observation: ====================== Websphere Partner Gateway During interoperability testing of WPG, a business partner is sending a compressed, signed and encrypted document to WPG. The document has to be decrypted, signature has to be verified and decompression has to be done. During decryption, it is observed that about 25 to 29 minutes are taken in parsing the ContentInfo structure. The problem is most likely because of the document structure. The document contains a constructed Octet String component with indefinite length encoding, which contains lot of small Octet String components having length 34 or 26 bytes. Another document having the same structure, but having the Octet String components of more length i.e. 2048 bytes or 4096 bytes, is processed completely in WPG in 1 minute or so.
Level 3 to update
During interoperability testing of WPG (WebSphere Partner Gateway), a business partner is sending a compressed, signed, and encrypted document to WPG. The document has to be decrypted, signature has to be verified, and decompression has to be done. It was observed that about 25 to 29 minutes was taken to process ContentInfo object created from this document. The logic within the PKCS utility class DerIndefLenConverter.java is being invoked to convert indefinite length DER encoded byte arrays taken from this document to definite length DER encoded byte arrays. The getIndefSeqSet( ) method within this utility class is incrementally processing the document data by allocating a new byte array to contain both "all data processed on previous iterations" plus "all data processed on the most recent iteration", and then copying both sets of data into this newly allocated byte array. This is done on each iteration. This processing is not only redundantly copying all the data processed so far on each iteration, it is also creating large numbers of byte arrays for disposal by the java garbage collector. The fix is to eliminate the logic which allocates a new byte array to contain the data on each iteration, and replace it with logic which simply appends the data to an ArrayList - that is, a data structure that can grow. This problem affects the 1.4.2, 5.0, and 6.0 releases.
This problem will be repaired in 1.4.2 SR14, 5.0 SR10 and 6.0 SR5 under Austin CMVC defect 106583 (Hursley defect 148597). The associated Austin CMVC build level is 20090331_02 for the PKCS142 release. The associated Austin CMVC build level is 20090331 for the pkcs15 and pkcs16 releases. The problem was repaired within the PKCS component, specifically file ibmpkcs.jar.
Reported component name
TIVOLI JAVA PKC
Reported component ID
Last modified date
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fixed component name
TIVOLI JAVA PKC
Fixed component ID
Applicable component levels
More support for:
Tivoli Components - Java Security
Software version: 100
Reference #: IZ47986
Modified date: 2009-04-06