Page tree
Skip to end of metadata
Go to start of metadata

X9.62 provides 3 alternatives for the parameters that can be found in an EC public key.

One of these is named implicitlyCA and indicates that the parameters are defined else where, implicit in the name of the certification authority (CA) that issued the key. In this stiuation the actual parameters appear in the ASN.1 encoding of the key as a DER encoded NULL, and calling getParameters on BC ECKey interface, or getParams() on the JDK ECKey interface will return the null value.

As the definition says, when the key is used, the parameters will have to come from elsewhere. In the case of the BC provider the interface ConfigurableProvider is defined in the org.bouncycastle.jce.interfaces package. The interface is implemented by the Bouncy Castle provider and allows for the configuration of implicit parameters where they are required using one of two modes:

  • providing the parameters so they can be accessed anywhere within the same JVM using ConfigurableProvider.EC_IMPLICITLY_CA
  • providing the parameters so they can only be accessed by the current thread using ConfigurableProvider.THREAD_LOCAL_EC_IMPLICITLY_CA.

In some cases having unlimited access to this facility in a JVM would not be regarded as a god thing. If necessary the ability to access this facility can also be protected using the org.bouncycastle.jce.ProviderConfigurationPermission. Details about this are described in the last section of this document.

Global Setup of ImplicitlyCA Using the Bouncy Castle EC API

We can use the ConfigurableProvider interface to set the implicitlyCA parameter as follows:

From this point on any key with a null parameters field will be assumed to be using the ECParameterSpec that was passed in.

Global Setup of ImplicitlyCA Using the JDK EC (JDK 1.5 or later)

Alternately the implicitlyCA parameter can be set using an ECParameterSpec object from the JDK's java.security.spec package. The procedure is the same as that for the BC ECParameterSpec and the provider will internally translate the object into the format it needs.

Thread Local Setup of the ImplicitlyCA Parameter

The thread local case is the same as the setup of the global case and can also be used with both the BC API or the JDK API for elliptic curve.

For example, using the JDK 1.4 API you would write something like the following:

You can also pass config.setParameter() null as a parameter value. This can be useful if you not only want to restrict the use of implicitlyCA to a particular thread, but to a particular section of code as well. For example, given a method called getImplicitParams() which takes a CA name and returns the CA's implicit parameters you could use the following code to carry out restricted operations:

Using the ImplicitlyCA Parameter to Generate Keys

Telling the BC provider to make use of the implicit parameters is then just a matter of passing in a null where a parameter object is expected, for example, to create a key pair:

The resulting keys, vKey and sKey can then be used to create ECDSA signatures, in the same manner as normal EC keys.

Note: it is important to remember that keys generated in this fashion will be encoded with their parameters block set to ASN.1 NULL. If you need to export them to another installation the other installation must have the same parameters set for ImplictlyCA to be able to use the keys.

Using the ImplicitlyCA Parameter with KeyFactory

In this case nothing is required other than making sure the implictlyCA parameter is set for either the current thread or globally for the VM. Once that is done the {{KeyFactory}} class can be used as normal:

Limiting Access to the ImplicitlyCA Facility Using Java Policy

In situations where you need to limit access to the implicitlyCA feature in the Bouncy Castle provider you can restrict it by running the JVM with a security manager and using a policy file.

As a simple example, assuming you are trying to run the implicitlyCA test case and you are including a security manager you would need the following command line:

and, at a minimum, the following policy file:

After that restricting the use of ImplicitlyCA is a matter of adding further restriction to the grant term in the policy statement. Note that either of the global or thread local implictlyCA facilities can be disabled by leaving out the corresponding action keyword in the ProviderConfigurationPermission declaration.

  • No labels