RFR(S): 8224727: Problem list 2 tests in security/infra/java/security/cert/CertPathValidator/certification

Hi, please review the problem listing of security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java and security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java until JDK-8202651 and JDK-8215546 are resolved. Bug: https://bugs.openjdk.java.net/brows

RFR(S): 8224729: sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java can't handle forward slash characters in Certificate Issuer Names

Hi, please review this fix for an issue that I've discovered when working with test security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java. It fails when the test tries to do the CRL verification of the certificate. It has issues in the LDAP implementation because of t

Re: RFR(S): 8224729: sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java can't handle forward slash characters in Certificate Issuer Names

Hi Christoph, I don't think this is the right fix. The LDAP URL in the Certificate is incorrect and the forward slash should be escaped. If we start to make workarounds in the code to accept certificates that are not properly encoded, it becomes a slipperly slope. I base my rationale on the f

RE: RFR(S): 8224729: sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java can't handle forward slash characters in Certificate Issuer Names

Hi Sean, ok, I see, you're fully correct. So I hereby withdraw my fix proposal. As for the exclusion of the test: I have requested it this morning anyway: https://mail.openjdk.java.net/pipermail/security-dev/2019-May/019966.html. So I would assume that you ask Actalis to reissue the certificate

Re: RFR(S): 8224727: Problem list 2 tests in security/infra/java/security/cert/CertPathValidator/certification

On 5/24/19 4:00 AM, Langer, Christoph wrote: Hi, please review the problem listing of security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java and security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java until JDK-8202651 and JDK-8215546 are re

Re: RFR: CSR for 8211018 Session Resumption without Server-Side State

jdk.tls.server.sessionTicketTimeout: Could we use the SSLSessionContext.getSessionTimeout() value for ticket session timeout? jdk.tls.server.statelessKeyTimeout: We may extend to use external key and key rotation to improve scalability. I was wondering, if it is possible to remove the propert

Re: RFR(S): 8224729: sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java can't handle forward slash characters in Certificate Issuer Names

On 5/24/19 8:48 AM, Langer, Christoph wrote: Hi Sean, ok, I see, you're fully correct. So I hereby withdraw my fix proposal. As for the exclusion of the test: I have requested it this morning anyway:https://mail.openjdk.java.net/pipermail/security-dev/2019-May/019966.html. So I would assume t

Re: RFR 8211018: Session Resumption without Server-Side State

SSLSessionContext.java -- As comment in the CSR review thread, I may not define the jdk.tls.server.sessionTicketTimeout property, and use one session timeout (SSLSessionContext.getSessionTimeout()) instead. The ticket timeout may be not necessary, read more please. Session

Re: RFR(S): 8224727: Problem list 2 tests in security/infra/java/security/cert/CertPathValidator/certification

I have pushed fix for ComodoCA with JDK-8202651 and have filed JDK-8224768 to address ActalisCA issue. You can problem list ActalisCA for now with JDK-8224727. Thanks, Rajan On 5/24/19 6:43 AM, Sean Mullan wrote: On 5/24/19 4:00 AM, Langer, Christoph wrote: Hi, please review the problem lis

Re: RFR: CSR for 8211018 Session Resumption without Server-Side State

On 5/24/19 6:44 AM, Xuelei Fan wrote: jdk.tls.server.sessionTicketTimeout: Could we use the SSLSessionContext.getSessionTimeout() value for ticket session timeout? The property is meant to complement the API. getSessionTimeout() will return the value of the property if it is set. I think

Re: RFR 8211018: Session Resumption without Server-Side State

On 5/24/19 8:51 AM, Xuelei Fan wrote: SSLSessionContext.java -- As comment in the CSR review thread, I may not define the jdk.tls.server.sessionTicketTimeout property, and use one session timeout (SSLSessionContext.getSessionTimeout()) instead. The ticket timeout may be no

Re: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client

Hi Xuelei, Thanks for your reply. I think I now know what you mean. Here it's a new benchmark: http://cr.openjdk.java.net/~mbalao/webrevs/8223482/benchmark_sslcontextloading_manual_v0.tar.gz In this new benchmark we measure the following sequence: long startTime = System.currentTimeMillis(); c

RFR: 8224767: Add String constants for Canonical XML 1.1 URIs

Please review this fix to add two new String constants to the XML Signature API for the Canonical XML 1.1 Algorithm URIs: webrev: http://cr.openjdk.java.net/~mullan/webrevs/8224767/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8224773 Thanks, Sean

Re: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client

The benchmark result looks good to me. I still have a few questions. Read inlines, please. On 5/24/2019 12:16 PM, Martin Balao wrote: Hi Xuelei, Thanks for your reply. I think I now know what you mean. Here it's a new benchmark: http://cr.openjdk.java.net/~mbalao/webrevs/8223482/benchmark_s

Re: RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806)

Hi Max, Thanks for your review. 1) src/java.security.jgss/share/classes/sun/security/krb5/KrbAsReqBuilder.java: * When NT-ENTERPRISE names are used, a "@" char can be part of the name and we should not interpret it as a realm separator. If we don't escape, we may be missing part of the name whe

Re: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client

Hi Xuelei, On 5/24/19 5:17 PM, Xuelei Fan wrote: > If I understand correctly, you run the test with the patch of webrev01? >    http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.01/ > Yes, this is correct. > >> FIPS_without_8223482_webrev01.txt average: 358.42 ms >> NON_FIPS_wi

Re: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6

On 5/23/19 8:14 PM, Arthur Eubanks wrote: Ping on a review from security-dev. On Fri, May 17, 2019 at 9:53 AM Chris Hegarty > wrote: Arthur, On 17 May 2019, at 17:50, Arthur Eubanks mailto:[email protected]>> wrote: Looks good. Tri

Re: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6

On Fri, May 24, 2019 at 1:56 PM Sean Mullan wrote: > On 5/23/19 8:14 PM, Arthur Eubanks wrote: > > Ping on a review from security-dev. > > > > On Fri, May 17, 2019 at 9:53 AM Chris Hegarty > > wrote: > > > > Arthur, > > > >> On 17 May 2019, at 17:50, Arth

Re: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6

On 5/24/19 4:56 PM, Sean Mullan wrote: On 5/23/19 8:14 PM, Arthur Eubanks wrote: Ping on a review from security-dev. On Fri, May 17, 2019 at 9:53 AM Chris Hegarty mailto:[email protected]>> wrote:     Arthur,     On 17 May 2019, at 17:50, Arthur Eubanks mailto:[email protected]>>

Re: [13] RFR JDK-8080462: Update SunPKCS11 provider with PKCS11 v2.40 support

Hi Sean, Thanks much for the suggestion. I have added the info on newly supported algorithms to both the CSR and the bug record. Please let me know if you have more comments. All, RFEs need to be integrated by 6/13. Can someone help reviewing this soon? Mach5 run is clean. I up'ed the versi

Re: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client

Good, I have no further comment for this update. Please go ahead. I think there is a possible improvement by calling Cipher.getInstance(algorithm) only one time for each transformation algorithm. But may not worthy as the duplicated transformation algorithm number is still small. I'm fine i

Re: RFR 8211018: Session Resumption without Server-Side State

I meant to avoid to use threads in the implementation of fundamental APIs. Xuelei On 5/24/2019 11:52 AM, Anthony Scarpino wrote: I would like to avoid to create thread in the fundamental API implementation if possible.  As the thread (KeyState.run()) is for invalid key cleanup only, the cleanu

RFR 8076999: SunJCE support of password-based encryption scheme 2 params (PBES2) not working

Hello all, happy Friday! Please review the following CSR and code review.  This makes updates to the SunJCE implementation of PBES2-based AlgorithmParameters.  Many of the details are in the CSR (see the link below).  But a short list of the updates: * Add DER Encode/Decode support for the

Re: RFR 8211018: Session Resumption without Server-Side State

Are you saying you don’t like any threads in the implementation? I don’t understand when you say “fundamental API” as there is. I way to call the thread via the public API Tony > On May 24, 2019, at 3:50 PM, Xuelei Fan wrote: > > I meant to avoid to use threads in the implementation of funda

Re: RFR 8211018: Session Resumption without Server-Side State

> On May 24, 2019, at 4:26 PM, Anthony Scarpino > wrote: > > Are you saying you don’t like any threads in the implementation? Right. > I don’t understand when you say “fundamental API” as there is. It’s a very personal preference of mine. Applications may not want to use threads. I don’t

Re: RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806)

> On May 25, 2019, at 4:43 AM, Martin Balao wrote: > > Hi Max, > > Thanks for your review. > > 1) > src/java.security.jgss/share/classes/sun/security/krb5/KrbAsReqBuilder.java: > > * When NT-ENTERPRISE names are used, a "@" char can be part of the name > and we should not interpret it as a

Re: RFR 8223053: [xmldsig] Add KeyValue::EC_TYPE

The CSR is approved. Are you OK with the schema definition referencing "ECParametersType" but not defining it. If yes, I'll push the change. Thanks, Nax > On May 14, 2019, at 8:50 AM, Weijun Wang wrote: > > > >> On May 13, 2019, at 10:51 PM, Sean Mullan wrote: >> >> On 5/10/19 8:07 PM, We

RE: RFR(S): 8224727: Problem list 2 tests in security/infra/java/security/cert/CertPathValidator/certification

Hi Rajan, thanks for this. Problem list update would be then: http://cr.openjdk.java.net/~clanger/webrevs/8224727.1/ Please review. Thanks Christoph > -Original Message- > From: Rajan Halade > Sent: Freitag, 24. Mai 2019 18:52 > To: Langer, Christoph > Cc: Sean Mullan ; security-dev

RE: RFR(S): 8224729: sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java can't handle forward slash characters in Certificate Issuer Names

> > As for Bug JDK-8224729: Shall I just close the ticket, dropping a comment > about the ignorance of the author or shall I repurpose it to do the other > cleanups in LDAPCertStoreImpl.java that I suggested? Don't know if these > are appreciated... what do you think? > > Either way, the debugging