The specification for the JAAS API does not facilitate writing pluggable
login modules for X.500 principals because it does not specify the way
that an X.500 principal's credentials should be stored.

The absence of a specification is especially problematic for X.500
principals because there is no easy way to tell what public key, X.509
certificate, or X.500 principal is associated with a particular private
key. As a result, the login module needs to store extra information to
make association, using a format of its own devising.

This issue came up while working on an JSSE-based RMI security provider.
The provider looks for X.500 principals and associated credentials in a
Subject.

Applications that use the provider need to have a compatible JAAS login
module. I have created a suitable login module, which retrieves
credentials from a KeyStore and uses instances of a class it supplies to
associate the credentials and principal. Although I could include this
login module with the provider, doing so would not fit well with JAAS's
pluggable login module approach. In addition, if JAAS were to provide a
similar login module in the future, it is unlikely that it would store
the credentials in a compatible way, since that would require using my
provider's class for associating principals and credentials. This
problem would be fixed if JAAS specified a standard way to store X.500
principal credentials.

What are the requirements for login modules and applications to
represent the relationship between an X.500 principal and its
credentials? For a particular X.500 principal, the public credentials
must include the associated X.509 certificate, which in turn provides
access to the public key. The public credentials should probably also
include the rest of the certificate chain, to assist authentication.

Since X.509 certificates identify the name of the associated X.500
principal, it is easy to associate the principal and its public
credentials.

The private credentials for an X.500 principal must include the private
key. Note that the PrivateKey interface, as well as its subinterfaces,
do not provide information about the associated principal, certificate,
or public key, so some separate mechanism is needed to make the
association.

Using an object that contains references to the private key and the
associated X.509 certificate as the private credential provides the
needed association. The private credential needs to identify the
certificate, not just the principal, because a given X.500 principal may
have more than one set of associated credentials. It is not necessary
to hold a reference to the entire certificate chain, though, since that
can be retrieved from the public credentials, given the certificate.

In my working version of the JSSE-based RMI security provider, I store
an X509Certificate array containing the X.509 certificate chain as the
public credential, and an instance of a class with references to the
private key and the certificate as the private one.

It would encourage interoperability for login modules and applications
using X.500 principals if two changes were made in JAAS:

* JAAS included a new class for associating a private key and an X.509
  certificate in a private credential.

* The JAAS X.500 principal class documented that its credentials should
  be stored in a subject by placing the certificate chain in the public
  credentials as an X509Certificate array, and putting an instance of
  the new class containing the X.509 certificate and private key in the
  private credentials.

Note that other types of principals would probably benefit from similar
specifications.