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.
