JavaTM Cryptography Extension (JCE) 1.2.2


Summary of Changes and Enhancements

This document lists the major changes and enhancements since the JCE 1.2 release. The current release, JCE 1.2.2, is a maintenance release of JCE 1.2.1. There are no new methods and classes in JCE 1.2.2. For easy reference, this document is divided into the following sections:

  • Bug Fixes and Changes in JCE 1.2.2
  • Bug Fixes and Changes in JCE 1.2.2

    Here is a list of major bug fixes/changes and their descriptions:

  • JCE has changed its signed jar verification routine to accept signed jars with legitimate certificates even if the certificate has expired. As a result, JCE services will not be disrupted even if the signer's certificate for a JCE provider has expired.
  • Depending on how providers register their implementations, provider lookup may return an implementation from a less-preferred provider. This error has been fixed so that provider lookup decision is solely based on the preference orders.
  • When verifying providers, JCE failed to correctly verify the provider certificate chain.
  • JCE used to read in the two jurisdiction policy files using the default encoding scheme. Since the two jurisdiction policy files are always encoded in UTF-8, JCE is modified to use UTF-8 regardless of the default.
  • Cipher.update(byte[] input, int offset, int len) threw a NullPointerException incorrectly when the input data is too short to result in a new block.
  • The HmacSHA1 and HmacMD5 implementation in "SunJCE" provider did not produce the correct MAC result if the key length is between 33 and 63 bytes.
  • The DESedeParameters implementation in "SunJCE" provider threw an ArrayIndexOutOfBoundsException if an 0-length byte array is specified in its init() calls. Now, an IOException is thrown in place of ArrayIndexOutOfBoundsException as specified in the API documentation.
  • "SunJCE" provider now returns 112 as the key size for all DESede keys since that is the effective key length for DESede keys.
  • Clarified the javax.crypto.Cipher and javax.crypto.CipherSpi API documentation.
  • Fixed errors in API documentation.

  • Features and New API

    The major new feature in JCE 1.2.1 is the exportability, as described in the section New Features. A few new methods and classes have been added in JCE 1.2.1.

    This document is divided into the following sections:

    1. New Features
    2. New Classes
    3. New Methods
    1. New Features 
      1. Made JCE exportable. The JCE 1.2.2 framework is digitally signed. A provider must be signed by a trusted entity. Otherwise, the provider cannot be plugged into the JCE 1.2.2 framework. The JCE 1.2.2 framework and providers do mutual authentication at runtime. JCE 1.2.2 introduces an architecture which allows flexible cryptographic strength to be configured via jurisdiction policy files. This new feature doesn't cause any API changes, so it is transparent to JCE application developers. Note: The JCE 1.2.2 software from Sun Microsystems has a single distribution for both domestic and global users. The bundled jurisdiction policy files contain no restrictions on cryptographic strengths.

        Note for Cryptographic Service Providers (CSPs, also known as "providers"): The document How to Implement a Provider for JavaTM Cryptography Extension 1.2.2 contains information about how to ensure your provider will work with the JCE 1.2.2 framework. 

      2. Added support for key wrapping.

      3. Added support for key usage control.

    2. New Classes 
      1. Added javax.crypto.ExemptionMechanism. An applet or application utilizing an exemption mechanism (such as key recovery) implemented by a provider may be allowed to use cryptography of greater strength than that allowed by default (based on jurisdiction policy files).

        Justification: Customer request.

        Note for CSPs: Added corresponding SPI class javax.crypto.ExemptionMechanismSpi

        Note: The SunJCE provider does not provide an implementation for this class.

    3. New Methods 
      1. Added wrap(java.security.Key key) and unwrap(byte[] wrappedKey) methods to javax.crypto.Cipher, which allow users to do key wrapping. 

        Justification: Customer request.

        Note for CSPs: Added corresponding SPI methods engineWrap(java.security.Key key) and engineUnwrap(byte[] wrappedKey) in javax.crypto.CipherSpi.

      2. Added init(int opmode, java.security.cert.Certificate certificate) and init(int opmode, java.security.cert.Certificate certificate, java.security.SecureRandom random) methods to javax.crypto.Cipher, which enable a Cipher to be initialized from a key within a certificate (rather than from a key directly), and which may enforce key usage control. 

        Justification: Customer request.

      3. Added engineGetKeySize(java.security.Key key) in javax.crypto.CipherSpi, which returns the size of the given key. 

        Justification: To enforce jurisdiction policies, the JCE needs to know the key size. The CipherSpi class is the best place to add this method. Note: This is a protected SPI method. There is no corresponding API method.

        Note for CSPs: This method must be overridden by the CSP if the CSP may be exported to a country whose government mandates cryptographic restrictions. For such a country, a JCE 1.2.2 framework vendor may create a download bundle that includes jurisdiction policy files that specify required cryptographic restrictions. Users in that country could download the bundle, and the JCE 1.2.2 framework will enforce the specified restrictions. Such enforcement requires calls to engineGetKeySize.

     



    CHANGES | README | LICENSE | COPYRIGHT
    INSTALL | FAQ | KNOWN BUGS | SUBMIT BUGS

     

    Unless otherwise licensed, code in all
    technical manuals herein (including articles,
    FAQs, samples) is provided under this License.


    Copyright © 1995-2002 Sun Microsystems, Inc.
    All Rights Reserved. Terms of Use. Privacy Policy.