[security-dev 00507]: Re: SSLContextFactory
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
[security-dev 00508]: Re: SSLContextFactory
Hi Bruno, 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). Do you find that there are still many use cases that require you to manually add CRLs? Most CAs that I know of now include the information to obtain CRLs in the certificate itself, in the CRL Distribution Point Extension. We support this extension in our PKIX CertPath implementation. The implementation will automatically download these CRLs and cache them in memory for a short time. However, you must enable the system property com.sun.security.enableCRLDP to the value true. We should probably change it to be enabled by default because I don't think many users know about this property and it is somewhat buried in the CertPath docs in one of the appendices. --Sean
[security-dev 00510]: Re: SSLContextFactory
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]:
[security-dev 00511]: hg: jdk7/tl/jdk: 6476425: (fmt)java.util.Formatter.print() throws IllegalArgumentException on large BigDecima
Changeset: 63f8707112be Author:sherman Date: 2009-01-22 20:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/63f8707112be 6476425: (fmt)java.util.Formatter.print() throws IllegalArgumentException on large BigDecima Summary: Correct the wrong calculation of precision in certain circumstances. Reviewed-by: darcy, alanb ! src/share/classes/java/util/Formatter.java ! test/java/util/Formatter/Basic-X.java ! test/java/util/Formatter/Basic.java ! test/java/util/Formatter/BasicBigDecimal.java ! test/java/util/Formatter/BasicBigInteger.java ! test/java/util/Formatter/BasicBoolean.java ! test/java/util/Formatter/BasicBooleanObject.java ! test/java/util/Formatter/BasicByte.java ! test/java/util/Formatter/BasicByteObject.java ! test/java/util/Formatter/BasicChar.java ! test/java/util/Formatter/BasicCharObject.java ! test/java/util/Formatter/BasicDateTime.java ! test/java/util/Formatter/BasicDouble.java ! test/java/util/Formatter/BasicDoubleObject.java ! test/java/util/Formatter/BasicFloat.java ! test/java/util/Formatter/BasicFloatObject.java ! test/java/util/Formatter/BasicInt.java ! test/java/util/Formatter/BasicIntObject.java ! test/java/util/Formatter/BasicLong.java ! test/java/util/Formatter/BasicLongObject.java ! test/java/util/Formatter/BasicShort.java ! test/java/util/Formatter/BasicShortObject.java ! test/java/util/Formatter/genBasic.sh
