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.