As an intern for Sun Labs, I have been working on a project that
involves providing a Certification Path-based trust manager and key
manager for JSSE. This should allow full PKIX-compliant Certification
Path handling for JSSE, including revocation checking. The JSSE
classes have worked well, and at this point we have a working version.
In implementing an X509KeyManager and an X509TrustManager to
accomplish this goal, we had some thoughts and encountered some
problems that we would like to share with you.

First, the Java docs for classes in the com.sun.net.ssl package are
underspecified. For instance, the chooseClientAlias method of the
X509KeyManager interface lacks sufficient information about return
values. We understand that these are not supported APIs.
Nonetheless, they are documented in the JSSE distribution, and it
would be much better if the documentation were thorough and complete.

Next, we have discovered a certain degree of inflexibility in the
X509KeyManagerFactory and X509TrustManagerFactory classes. The
problem is that there is no way to pass arbitrary initialization
parameters to our TrustManager and KeyManager objects. We need to do
this so that we can tell the TrustManager where we can get CRLs, for
instance. Since the provider system requires that applications do not
directly instantiate or call methods on these objects directly, the
application must obtain individual Factory objects using the
getInstance method, and then provide the parameters with the init
method for the newly created Factory object. However, the init method
only takes a keystore (and password). We hacked up a solution using
static methods in our KeyManagerFactory and TrustManagerFactory
objects to set these parameters; the Factories in turn pass the
parameters along to each newly created object.

We believe that since the provider system prevents applications from
calling methods on library classes directly, the interfaces should
allow for greater flexibility for extending functionality in ways that
require additional parameters from the application. One possibility
is the modification of the TrustManagerFactorySpi and
KeyManagerFactorySpi objects to allow an additional "parameters"
Object in the engineInit method. So, when the current engineInit
method header for the KeyManagerFactorySpi looks like this...

protected abstract void engineInit(java.security.KeyStore ks,
char[] password)

...the revised header would look like this:

protected abstract void engineInit(java.security.KeyStore ks,
                                   char[] password,
Object parameters)

Both methods would exist in the KeyManagerFactorySpi. This in turn
would allow an arbitrary data type to be passed from the application
without the need to resort to static methods, packing serializations
of the parameters into flexible data types, or other undesirable
workarounds.

Also, consider for example the X509KeyManager interface. The
documentation for the chooseClientAlias and chooseServerAlias methods
in the X509KeyManager interface suggests that the function should
select a particular certificate chain from an array. We figured that
since ours is a reference implementation, we could simply select an
arbitrary certificate, but more complex implementations may require
additional parameters from the application. We believe that similarly
to the init method, this method would benefit from a "parameters" object
as well.