RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
Hello, Could you please review the following patch: JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ The Windows LDAP server with LdapEnforceChannelBinding=2 uses the tls-server-end-point channel binding (based on the TLS server certificate). The channel binding data is calculated as following : • The client calculates a hash of the TLS server certificate. The hash algorithm is selected on the base of the certificate signature algorithm. Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 based • The channel binding information is the same as defined in rfc4121 [1] with small corrections: • initiator and acceptor addresses should be set to NULL • initiator and acceptor address types should be zero. It contradicts to the “Using Channel Bindings in GSS-API” document [2] that say that the address type should be set to GSS_C_AF_NULLADDR=0xFF, instead of GSS_C_AF_UNSPEC=0x00. This patch introduces changes in the LDAP, SASL and JGSS modules to generate channel binding data automatically if requested by an application. This patch reuses existing org.ietf.jgss.ChannelBinding class implementation but changes initial unspecified address type from CHANNEL_BINDING_AF_NULL_ADDR to CHANNEL_BINDING_AF_UNSPEC. The patch introduces new environment property “com.sun.jndi.ldap.tls.cbtype” that indicates Channel Binding type that should be used in the LDAPS connection over JGSS/Kerberos. Right now "tls-server-end-point" Channel Binding type is supported only. The client extracts server certificate from the underlying TLS connection and creates Channel Binding data for JGSS/Kerberos authentication if application indicates com.sun.jndi.ldap.tls.cbtype=tls-server-end-point property. Client application should also specify existing "com.sun.jndi.ldap.connect.timeout” property to force and wait TLS handshake completion before JGSS/Kerberos authentication data is generated. [1] - https://tools.ietf.org/html/rfc4121#section-4.1.1.2 [2] - https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/index.html Initial discussion of this issue is available at security-dev list: https://mail.openjdk.java.net/pipermail/security-dev/2019-December/021052.html https://mail.openjdk.java.net/pipermail/security-dev/2020-January/021140.html https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021278.html https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021864.html signature.asc Description: Message signed with OpenPGP
RFR[15] JDK-8243114: Implement montgomery{Multiply, Square}intrinsics on Windows
Hello, I'd like to request a review for: JBS: https://bugs.openjdk.java.net/browse/JDK-8243114 Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8243114-jdk/00/00/ This change implements the given intrinsics on Windows. The Windows toolchain has no 128 bit integer types, and no inline asm (on x64 and Arm). In addition, 'long' is 4 bytes, not 8, as it is with gcc. This patch had to change some of the linux implementation to account for these limitations. My gratitude for Andrew Haley for doing the heavy lifting at the core of this patch. The patch, if accepted, will be offered to 11u as a potential backport. The changes apply cleanly modulo some line number changes. As for the speedup, this test case: BigInteger base = BigInteger.ONE.shiftLeft(1024); long count = LongStream.rangeClosed(2, 100_000) .mapToObj(n -> BigInteger.valueOf(n).add(base)) .filter(i -> i.isProbablePrime(50)) .count(); goes from 1 minute 20 seconds down to about 35 seconds om my VM, over multiple runs. As is the case on other platforms where the intrinsics are supported, they will be enabled by default on Windows. Thank you for your time, -Simon Tooke Principle Software Engineer, Red Hat Canada
Re: RFR[15] JDK-8245134: test/lib/jdk/test/lib/security/KeyStoreUtils.java should allow to specify aliases
On 5/20/2020 7:38 PM, sha.ji...@oracle.com wrote: - line 176, maybe it's better to just supply the type, clearer and less dependency. Not get this point. Could you please describe some more? I mean to change line 176 as below (see the added text in blue): 176 return createTrustStore(DEFAULT_TYPE, certStrs, null); With this extra aliases argument, number of createTrustStore(...) methods doubled from 2 to 4, number of createKeyStore(...) methods also doubled from 4 to 8. Isn't it a bit much to have 8 methods doing the same thing? Especially in the case of createKeyStore(...), quite a few of them have long list of arguments with the same type, combining this with the large number of methods, it can get confusing on which method is called. How often do you think the aliases are supplied? Maybe we only add methods which will be used instead of adding all possible combinations. I'll remove 4 createKeyStore(...) methods (like the below one) that have long list of arguments. createKeyStore(String type, String[] keyAlgos, String[] keyStrs, String[] passwords, String[] certStrs, String[] aliases) It looks no test is using them. My tests also won't use them. Sounds good. Thanks, Valerie Best regards, John Jiang Thanks, Valerie On 5/15/2020 11:40 PM, sha.ji...@oracle.com wrote: Hi, This patch adds some new createTrustStore() and createKeyStore() methods to test lib class jdk.test.lib.security.KeyStoreUtils. These new methods allow to pass trust/key store aliases in. Issue: https://bugs.openjdk.java.net/browse/JDK-8245134 Webrev: http://cr.openjdk.java.net/~jjiang/8245134/webrev.00/ Best regards, John Jiang
Re: RFR[15] JDK-8245134: test/lib/jdk/test/lib/security/KeyStoreUtils.java should allow to specify aliases
Hi Valerie, Thanks for your clarification! Could you please review this updated webrev: http://cr.openjdk.java.net/~jjiang/8245134/webrev.01/ Best regards, John Jiang On 2020/5/22 06:08, Valerie Peng wrote: On 5/20/2020 7:38 PM, sha.ji...@oracle.com wrote: - line 176, maybe it's better to just supply the type, clearer and less dependency. Not get this point. Could you please describe some more? I mean to change line 176 as below (see the added text in blue): 176 return createTrustStore(DEFAULT_TYPE, certStrs, null); With this extra aliases argument, number of createTrustStore(...) methods doubled from 2 to 4, number of createKeyStore(...) methods also doubled from 4 to 8. Isn't it a bit much to have 8 methods doing the same thing? Especially in the case of createKeyStore(...), quite a few of them have long list of arguments with the same type, combining this with the large number of methods, it can get confusing on which method is called. How often do you think the aliases are supplied? Maybe we only add methods which will be used instead of adding all possible combinations. I'll remove 4 createKeyStore(...) methods (like the below one) that have long list of arguments. createKeyStore(String type, String[] keyAlgos, String[] keyStrs, String[] passwords, String[] certStrs, String[] aliases) It looks no test is using them. My tests also won't use them. Sounds good. Thanks, Valerie Best regards, John Jiang Thanks, Valerie On 5/15/2020 11:40 PM, sha.ji...@oracle.com wrote: Hi, This patch adds some new createTrustStore() and createKeyStore() methods to test lib class jdk.test.lib.security.KeyStoreUtils. These new methods allow to pass trust/key store aliases in. Issue: https://bugs.openjdk.java.net/browse/JDK-8245134 Webrev: http://cr.openjdk.java.net/~jjiang/8245134/webrev.00/ Best regards, John Jiang
