Bruno Harbulot wrote:
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, ...).

Because the JSSE has already provided the TrustManagerFactory and
KeyManagerFactory, and one can customize the trust manager and key
manager with simple processes, I don't think the SSLContextFactory is a
have-to-have interface, although is is cool knife for some application.

Personally, I would prefer a library or a provider that gives many
customized trust managers and key managers, and then the programmers
join them into SSLContext by SSLContext.init() according to their
requirements.
This being said, perhaps the main Java API isn't the right place for this. It can be in a separate library indeed.

Yes, it is of great help for some certain applications, but just as you
said, I really don't think it should be in JRE level.

Thanks,
Andrew
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 anor the SSLContextFactory, ind 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. F 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.



Reply via email to