Re: [15] RFR 8241761 : Typos: empty lines in javadoc, inconsistent indents, etc. (security-libs only)

Thank you Max! I've made the suggested adjustment and pushed the fix. With kind regards, Ivan On 4/1/20 2:59 AM, Weijun Wang wrote: Looks fine to me. If I have to pick one tiny problem, you can remove a blank in line 58 below to make the indentation more precise: src/java.security.sasl/sha

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: [email protected] 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 r

Re: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339)

I can agree with #2. We won’t be setting a precedent by returning null. Either 1 or 2 allow us to better support a future RFC with an encoding. #3, probably creates more potential problems than we need. I believe a majority of EdDSA usage doesn’t use the parameters. As far as I know browsers

Re: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339)

I just read https://tools.ietf.org/html/rfc8410 and it intentionally did not encode prehash and context anywhere. If AlgorithmParameters' main purpose is to decode/encode this, then looks like it's useless here. The EDDSA case is quite unusual because normally anything set by setParameter on th

Re: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339)

On 4/1/20 6:44 PM, Weijun Wang wrote: Two comments: 1. Signature::getParameters explicitly specifies that the return value should match that set in setParameter(). Therefore although the types of params are different we need to make sure the contents are essentially the same. This means the g

Re: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339)

Two comments: 1. Signature::getParameters explicitly specifies that the return value should match that set in setParameter(). Therefore although the types of params are different we need to make sure the contents are essentially the same. This means the getParameters() result should be designed

Re: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339)

I understand what the spec says, but here is why I believe the code returns UOE. EdDSASignature.setParameters only takes EdDSAParameterSpec and does not take NamedParameterSpec, which can define the curve. The curve is defined during getInstance(). While there is an ASN.1 for the curve t

Re: RFR 8241888: Mirror jdk.security.allowNonCaAnchor system property with a security one

Hi Sean, Thanks for having a look at this. On 4/1/20 4:47 PM, Sean Mullan wrote: > > 65  * System property that if set (or set to "true"), allows trust > anchor > > Change this to "System or security property ..." Fixed. > > - Update the copyright date. Fixed. > > * java.security > >

Re: Possible regression in JDK 14 related to SSLSessionContext / SSLSession on the server side

Hi Norman, session context issue is here: https://bugs.openjdk.java.net/browse/JDK-8242008 --Jamil On 4/1/2020 12:32 AM, Norman Maurer wrote: Please add a link to the bug once it is created. Bye Norman On 31. Mar 2020, at 17:35, Jamil Nimeh > wrote: Thanks

Re: RFR 8241888: Mirror jdk.security.allowNonCaAnchor system property with a security one

On 3/30/20 7:58 PM, Martin Balao wrote: Hi, I'd like to request a review for 8241888 [1]. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8241888/8241888.webrev.00/ * PKIXValidator 65 * System property that if set (or set to "true"), allows trust anchor Change this to "Sys

Evaluation part 1 of JDK-6722928: Provide a default native GSS-API library on Windows

Hi Max, at last I took some time to evaluate you SSPI bridge. This is part one. Interaction evaluation will follow in a second email. Assumptions: * All methods, objects behave the same as with JGSS * AcceptSecurityContext is not implemented so should everything associated with it fail (GSSEx

Re: [15] RFR 8241761 : Typos: empty lines in javadoc, inconsistent indents, etc. (security-libs only)

Looks fine to me. If I have to pick one tiny problem, you can remove a blank in line 58 below to make the indentation more precise: src/java.security.sasl/share/classes/javax/security/sasl/SaslServer.java: 57 * status = ldap.sendBindResponse(mechanism, challenge, 58 *

Re: Possible regression in JDK 14 related to SSLSessionContext / SSLSession on the server side

Please add a link to the bug once it is created. Bye Norman > On 31. Mar 2020, at 17:35, Jamil Nimeh wrote: > > Thanks Norman, I'm going to file a bug on this one. After playing with it a > bit more I found cases where even SSLServerSockets do run into the issue but > it doesn't always happ

Re: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339)

While SignatureSpi says engineGetParameters() would throw an UOE when it's not overridden, it is not specified in Signature::getParameters: * If this signature has been previously initialized with parameters * (by calling the {@code setParameter} method), this method returns * the