JavaTM Cryptography Extension (JCE) 1.2.1

Summary of Changes and Enhancements

This document lists all the changes and enhancements since the JCE 1.2 release.

The major new feature in JCE 1.2.1 is the exportability. This feature is further explained in the section New Features. There are also a few new methods and classes in JCE 1.2.1.

This document is divided into the following sections:

- New Features
- New Classes
- New Methods

1. New Features
   1. Made JCE exportable. The JCE 1.2.1 framework is digitally signed. A provider must be signed by a trusted entity. Otherwise, the provider cannot be plugged into the JCE 1.2.1 framework. The JCE 1.2.1 framework and providers do mutual authentication at runtime. JCE 1.2.1 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.1 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.1 contains information about how to ensure your provider will work with the JCE 1.2.1 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: In order 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.1 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.1 framework will enforce the specified restrictions. Such enforcement requires calls to `engineGetKeySize`.