Hi Xuelei,
Thanks for looking into this.
I agree with you, everything that's required is already in the JavaSE
API. I find, however, that using these classes requires a careful
reading of the JSSE ref. guide and the Certification path ref. guide,
both of which are rather long and non-trivial (at least to me). I
suspect many developers don't have time to get into such a depth of details.
One of the use-cases that was the motivation for PKIXSSLContextFactory
in jSSLutils was to be able to add CRLs quite easily. Thus, you get
something like this:
PKIXSSLContextFactory sslContextFactory =
new PKIXSSLContextFactory(keyStore, "keypassword", trustStore);
sslContextFactory.addCrl("http://ca.example.org/root-crl";);
sslContextFactory.addCrl("http://ca.example.org/intermediate-crl";);
SSLContext sslContext = sslContextFactory.buildSSLContext();
It's true that it's not possible to cover all cases, but I would guess
that there is small set of cases that are more frequent (such as adding
CRLs explicitly).
Even some high-profile projects don't necessarily handle this case, or
haven't been doing it for a long time (for example, as far as I can see,
CRL support was added to Tomcat only in 2006, and it accepts only one
CRL file).
I was only suggesting that an SSLContext factory be added to the main
API because it seems that a few projects create their own (named one way
or another). Having an SSLContextFactory interface and perhaps a default
PKIX-based implementation (or following the default value) that would
take a keystore and truststore (or fall back to either default values)
might help harmonise the practice amongst various projects (such as
Tomcat, Grizzly/Glassfish, Jetty, Restlet, ...).
This being said, perhaps the main Java API isn't the right place for
this. It can be in a separate library indeed.
Best wishes,
Bruno.
Xuelei Fan wrote:
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.
