Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

> On May 27, 2020, at 1:46 AM, Alexey Bakhtin wrote: > > Hello Max, > > Thank you review. > If I understand correctly tls-server-end-point channel binding data is a hash > of server certificate. Different SASL protocols could send cbData > differently, with different prefix format. Not

Re: RFR 8244565: Accept PKCS #8 with version number 1

Can you please take a look (not a review) at an updated webrev at http://cr.openjdk.java.net/~weijun/8244565/webrev.02/? It contains the code to inspect the extra fields. I haven't deal with the "..." here yet. However, when I tried to consolidate the DER parsing into one place, I've made more

Re: RFR 8242068: Signed JAR support for RSASSA-PSS and EdDSA

Webrev updated at http://cr.openjdk.java.net/~weijun/8242068/webrev.01/ Two major changes: 1. Always use the signature algorithm directly in SignerInfo::signatureAlgorithm: In PKCS7 SignerInfo SignerInfo ::= SEQUENCE { version CMSVersion, sid SignerIdentifier,

Re: RFR 8244565: Accept PKCS #8 with version number 1

I suppose we can allow trailing data to conform to "..." then. But the "[[2: publicKey [1] PublicKey OPTIONAL ]]," line mean that the publicKey should not be present for V1? This should be checked? Valerie On 5/25/2020 9:02 PM, Weijun Wang wrote: The new definition at

Re: RFR JDK-8240871: SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3

On 5/26/2020 1:26 PM, Anthony Scarpino wrote: On 5/13/20 1:44 PM, Xuelei Fan wrote: On 5/13/2020 9:41 AM, Anthony Scarpino wrote: On 4/30/20 10:19 AM, Xuelei Fan wrote: Hi, Could I get the following update reviewed: http://cr.openjdk.java.net/~xuelei/8240871/webrev.00/ For TLS 1.3 full

Default algorithm for new SecureRandom()

Dell Customer Communication - Confidential Hi, While we appreciate that a performance issue was fixed in JDK-7092821, the issue JDK-8228613 which results in new SecureRandom() being

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

I am also concerned about the changes in GSSLibStub.c about the default value being GSS_C_AF_UNSPECinstead of GSS_C_AF_NULLADDR (line 194-195). Can you try and see if Window works with GSS_C_AF_NULLADDR? If yes, I'd prefer to not changing the default value for addresstype for the same reason

Re: RFR JDK-8240871: SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3

On 5/13/20 1:44 PM, Xuelei Fan wrote: On 5/13/2020 9:41 AM, Anthony Scarpino wrote: On 4/30/20 10:19 AM, Xuelei Fan wrote: Hi, Could I get the following update reviewed: http://cr.openjdk.java.net/~xuelei/8240871/webrev.00/ For TLS 1.3 full handshake, if the last handshake flight wraps

Re: RFR[15] JDK-8245134: test/lib/jdk/test/lib/security/KeyStoreUtils.java should allow to specify aliases

Looks good. Cleaner and shorter this way~ Thanks, Valerie On 5/21/2020 8:18 PM, sha.ji...@oracle.com wrote: 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

Re: RFR JDK-8240871: SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3

Ping ... On 5/13/2020 1:44 PM, Xuelei Fan wrote: On 5/13/2020 9:41 AM, Anthony Scarpino wrote: On 4/30/20 10:19 AM, Xuelei Fan wrote: Hi, Could I get the following update reviewed: http://cr.openjdk.java.net/~xuelei/8240871/webrev.00/ For TLS 1.3 full handshake, if the last handshake

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Not completely sure about which of the involved apIs have what possible extensions. Maybe we can somehow make two mechanisms one which is the compatible default and one would be the rfc compliant method. Then SASL can be configured and use different mechanism names with a new propert? That

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Hello Max, Thank you review. If I understand correctly tls-server-end-point channel binding data is a hash of server certificate. Different SASL protocols could send cbData differently, with different prefix format. This is a reason I create TLSChannelBinding class and calculate hash from the

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Hello Aleks, Daniel, Thank you for your comments. I don’t like that the code is split into several modules too. The reason of doing it is I can not get TLS server certificate from the JGSS/Kerberos code. The only place Where I can fetch it is LdapClient. If I understand your idea correctly, I

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Hi Alexey, I agree with all Daniel's comments. Few thoughts about moving the implementation down to SASL layers: Will it be possible to make this new code specific only for JGSS/Kerberos authentication mechanism? Maybe investigate moving all the new code to GssKrb5Client SASL client

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

I have a question on GssKrb5Client.java: Do you think it's a good idea to let the SASL mechanism understand what TLS binding is? Instead of passing the whole TlsChannelBinding object through a SASL property, is it possible to only pass the actual cbData? After all, the name

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Hi Alexey, This is not a review. A few high level comments however: For that kind of change that introduce a new environment property you will need to file a CSR, and probably provide some release notes as well. Your changes seem to trigger new IllegalStateException and

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Hi Michael, Thomas, Unfortunately we can not fix address type issue with the UnspecEmptyInetAddress subclass. We can not create subclass of InetAddress without changing public API. We can try similar approach but create subclass of ChannelBinding class instead. It is not so elegant like