Hi Bruno,
I have read your jsslutils project times, it is a really good practice
to wrap complex logics into a simple one.
By my understanding (If I'm wrong or something missed, correct me), the
underlying requirements for SSLContextFactory are:
1. multiple SSLContext instances per thread or request.
2. customizable key/trust managers.
3. support CRLs.
Let's discuss it one by one:
1. multiple SSLContext instances per thread or request.
SSLContext.init(KeyManager[], TrustManager[], SecureRandom)[1][2]
could be used to create SSLContext at anytime you want to.
2. customizable key/trust managers.
KeyManagerFactory[3] defines two initialization methods,
KeyManagerFactory.init(KeyStore, char[]) and
KeyManagerFactory.init(ManagerFactoryParameters). Both of the methods
could be used to customized the key managers.
Similarly, TrustManagerFactory[4] also defines two initialization
methods, TrustManagerFactory.init(KeyStore, char[]) and
TrustManagerFactory.init(ManagerFactoryParameters). Both of the methods
could be used to customized the trust managers.
Once the customized key/trust managers created, you can use the
above SSLContext.init() method for a customized SSLContext.
3. support CRLs.
It is flexible to support CRLs for trust managers with
TrustManagerFactory.init(ManagerFactoryParameters), please refer to
[5]-[10] step by step.
OK, by now, the current interfaces meets your requirements, I think. So,
I'm not really want to add a new SSLContextFactory.
And Cert path build and validation is a very very complex process for
enterprise environments, which concerns policies, constraint, date,
cross trust, etc. I don't think there is a simple way to hide the
complex in a general API. For the SSLContextFactory, in order to
provider enough candidate for various policies, constraints, a dozen of
sub-class must be defined, I don't think it is good.
So, because the TrustManagerFactory/KeyManagerFactory has provide the
flexibility, I don't think we still need a SSLContextFactory any more.
Thanks,
Xuelei
[1]: http://java.sun.com/javase/6/docs/api/javax/net/ssl/SSLContext.html
[2]:
http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLContext
[3]:
http://java.sun.com/javase/6/docs/api/javax/net/ssl/KeyManagerFactory.html
[4]:
http://java.sun.com/javase/6/docs/api/javax/net/ssl/KeyManagerFactory.html
[5]:
http://java.sun.com/javase/6/docs/api/javax/net/ssl/ManagerFactoryParameters.html
[6]:
http://java.sun.com/javase/6/docs/api/javax/net/ssl/CertPathTrustManagerParameters.html
[7]:
http://java.sun.com/javase/6/docs/api/java/security/cert/CertPathParameters.html
[8]:
http://java.sun.com/javase/6/docs/api/java/security/cert/PKIXBuilderParameters.html
[9]:
http://java.sun.com/javase/6/docs/api/java/security/cert/PKIXParameters.html
[10]:
http://java.sun.com/javase/6/docs/api/java/security/cert/PKIXParameters.html#setCertStores(java.util.List)
[11]:
http://java.sun.com/javase/6/docs/technotes/guides/security/certpath/CertPathProgGuide.html#StorageClasses
Bruno Harbulot wrote:
Hello,
I only found out recently about Sean Mullan's blog entry named
"Security Feature Planning for JDK 7" (written almost two years ago)
<http://weblogs.java.net/blog/mullan/archive/2006/08/security_featur.html>.
After I contacted him, he kindly suggested this mailing-list could be
the right place to discuss security features in JDK 7.
I've recently been trying to improve SSL support in a couple of
open-source projects. This led me to build a small library, which I've
called 'jsslutils' <http://code.google.com/p/jsslutils/>.
The idea behind this library is to provide an SSLContextFactory which
can help configure an SSLContext for applications such as Restlet
<http://www.restlet.org/> (Grizzly, Simple or Jetty connectors) or
Jetty <http://www.mortbay.org/jetty/>. Sub-classes of
SSLContextFactory can provide extra features such as helping with the
configuration of CRLs, or customization of the Key/TrustManagers. (If
you wish to try it out, there are some jUnit tests in the subversion
repository.)
I would be interested in having your opinions regarding an
SSLContextFactory, and whether something similar may have already been
discussed. Looking at the JDK 7 API, there doesn't seem to be an such
a class/interface. This has been a rather useful feature for my
application so far, and it should make it easy to support CRLs for
example in something like Jetty. However, I'm not sure whether it
would be good to have something like this SSLContextFactory in JDK 7.
Perhaps there are other better ways to achieve these goals.
One of the main problems I still find is that few applications support
setting up the SSLContext, which makes it sometimes difficult to
configure more advanced features such as CRLs. Java 6 provides a way
to set a default SSLContext, but this is not ideal. Sometimes, various
connectors in the application may want to use different SSLContexts
(perhaps with different truststores and keystores). For example, I
would like to be able to set a specific SSLContext when using
JavaMail, but I haven't found any documentation making it possible to
set up the truststore and keystores independently, instead, it seems
to rely on the default system properties.
Best wishes,
Bruno.
