RFR[8u] JDK-8157035: Use stronger algorithms and keys for JSSE testing

Hi, Please review this patch for "JDK-8157035: Use stronger algorithms and keys for JSSE testing" Issue: https://bugs.openjdk.java.net/browse/JDK-8157035 Webrev: HYPERLINK

RE: [8u] RFR: 8074462: Handshake messages can be strictly ordered

Hi Xuelei, Thanks for quick review. All the points are valid and implemented with your suggestions. Thanks, Prasad.K -Original Message- From: Xuelei Fan Sent: Friday, June 29, 2018 8:17 PM To: Prasadrao Koppula ; security-dev@openjdk.java.net Subject: Re: [8u] RFR: 8074462

[11] RFR: 8187218: GSSCredential.getRemainingLifetime() returns negative value for TTL > 24 days.

Could you please review the changes Webrev: http://cr.openjdk.java.net/~pkoppula/8187218/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8187218 The tests was contributed by Weijun Wang. Thanks, Prasad.K

[8u] RFR: 8074462: Handshake messages can be strictly ordered

by: Sean Coffey and Prasadrao Koppula Thanks, Prasad.K

RE: [8u-dev] RFR JDK-8187218 & JDK-8131051, two krb5 fixes on renewable

Thanks Max for review, corrected all the coding style changes. Thanks, Prasad.K -Original Message- From: Weijun Wang Sent: Wednesday, September 19, 2018 9:09 PM To: Prasadrao Koppula Cc: security-dev@openjdk.java.net Subject: Re: [8u-dev] RFR JDK-8187218 & JDK-8131051, two krb5 f

RFR[jdk] 8237474: Default SSLEngine should create in server role

Hi, Could you please review this patch. Default server role mode was flipped in SSLEngine, to client role mode as part of SSL package code refactoring for TLSv1.3, this patch flips back default client role to server role in SSLEngine. webrev:

RE: RFR[jdk] 8237474: Default SSLEngine should create in server role

Thanks for review Sean, I will add test changes.   Thanks, Prasad.K   From: Seán Coffey Sent: Friday, February 7, 2020 6:20 PM To: Prasadrao Koppula ; security-dev@openjdk.java.net Subject: Re: RFR[jdk] 8237474: Default SSLEngine should create in server role   Looks ok to me Prasad

RE: RFR[jdk] 8237474: Default SSLEngine should create in server role

> -Original Message- > From: Daniel Fuchs > Sent: Friday, February 7, 2020 8:32 PM > To: Prasadrao Koppula ; Sean Coffey > ; security-dev@openjdk.java.net > Subject: Re: RFR[jdk] 8237474: Default SSLEngine should create in server role > > Hi Prasad, > >

RE: RFR[jdk] 8237474: Default SSLEngine should create in server role

, Prasad.K From: Prasadrao Koppula Sent: Friday, February 7, 2020 5:03 PM To: security-dev@openjdk.java.net Subject: RFR[jdk] 8237474: Default SSLEngine should create in server role Hi, Could you please review this patch. Default server role mode was flipped in SSLEngine, to client role mode

RE: RFR[jdk] 8237474: Default SSLEngine should create in server role

Gentle ping? Thanks, Prasad.K From: Prasadrao Koppula Sent: Monday, March 30, 2020 7:21 PM To: security-dev@openjdk.java.net Subject: RE: RFR[jdk] 8237474: Default SSLEngine should create in server role Hi, Added @implnote and updated test changes, here is the new webrev, please

RE: RFR[jdk] 8237474: Default SSLEngine should create in server role

s used to change the mode to true. > + * The JDK SunJSSE provider implementation returns false unless > + * {@link setUseClientMode(boolean)} is used to change the mode > + * to true. > > It's fine to leave the CSR as it is. > > Otherwise, looks fine to me. > > Xuelei

RE: How to backports make it into openJDK?

Hi,   HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8180834"JDK-8180834: Backported to Oracle JDK, 7u191. OpenJDK 7u maintainers are best to answer backport process and OpenJDK 7u porting discussions are best discussed on HYPERLINK

[15] RFR JDK-8246031: Hang observed with coherence SSLNIOServer test

Hi, Could you please review this patch. For timeout/interrupts, JDK11u+ releases, SSLSocket:getSession behavior is different, compare to JDK8u. i.e, connection is in open state for timeout/interrupts exception. For comparability reasons, this fix will close connection for getSession

RE: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering

Hi, Looks good to me, one question If first registered SecureRandom algo gets removed, getDefaultSecureRandomAlgorithm return stale data, a refresh required in remove? Thanks, Prasad.K >-Original Message- >From: Valerie Peng >Sent: Friday, June 5, 2020 2:52 AM >To:

RE: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering

>-Original Message- >From: Weijun Wang >Sent: Friday, June 5, 2020 8:24 PM >To: Prasadrao Koppula >Cc: Valerie Peng ; security-dev@openjdk.java.net >Subject: Re: [15] RFR JDK-8246613: Choose the default SecureRandom algo >based on registration ordering > >I d

RE: [15] RFR JDK-8246031: Hang observed with coherence SSLNIOServer test

t;Otherwise, looks good to me. > >Xuelei > >On 6/4/2020 8:13 AM, Prasadrao Koppula wrote: >> Hi, >> >> Could you please review this patch. For timeout/interrupts, JDK11u+ >> releases, SSLSocket:getSession behavior is different, compare to JDK8u. >> i.e

RE: [15] RFR JDK-8246031: Hang observed with coherence SSLNIOServer test

Thanks Xuelei, updated the code accordingly. Thanks, Prasad.K >-Original Message- >From: Xuelei Fan >Sent: Thursday, June 11, 2020 9:03 PM >To: Prasadrao Koppula ; security- >d...@openjdk.java.net >Subject: Re: [15] RFR JDK-8246031: Hang observed with coherence >SSLN

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos

On Sat, 15 Jan 2022 00:44:08 GMT, Weijun Wang wrote: >> It's actually a purely system property rather than a Net property at the >> moment (same as the other spnego ones). Maybe, I should convert them all to >> net properties, so they can be documented/set in that file? > > This system

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos

On Thu, 13 Jan 2022 12:10:11 GMT, Michael McMahon wrote: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS > (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) > authentication scheme. When enabled, the implementation preemptively includes > a