RFR 8193156 : Need to backout fixes for JDK-8058547, JDK-8055753, JDK-8085903

2017-12-06 Thread Ivan Gerasimov
Hello! A regression caused by the recent fixes of the ProtectionDomain cache was observed. Thus, it is proposed to revert the corresponding changes for now. Would you please approve this patch, which is actually an anti-delta of three mentioned fixes? BUGURL: https://bugs.openjdk.java.net/

Re: 1st round RFR 8191438: jarsigner should print when a timestamp will expire

2017-12-06 Thread Sean Mullan
When signing, I think we should always print when the timestamp will expire, even if it is 10 years from now. For the warning, I would bump it up 6 months to a year. (It could potentially be more than this - a fresh timestamp ideally should be good for > 5 years in my opinion). Perhaps we don't

Re: Support for ECParameters with explicit (not named) parameter spec

2017-12-06 Thread Bernd Eckenfels
It is however very likely that the HSM does not accept/allow/implement arbitrary curves which it does not know how to handle and optimize the arithmetics. Especially not when it also needs to create points. (And some vendors sell them for a premium...) Safenet HSMs seem to only accept parameter

Re: Support for ECParameters with explicit (not named) parameter spec

2017-12-06 Thread Adam Petcher
On 12/6/2017 11:39 AM, Max Fichtelmann wrote: We use a HSM to generate ECDSA Keys and are required to use the curve brainpoolP256r1. Although the HSM does not specifically support brainpool, it is possible to generate these keys by providing the specific Curve Parameters. These curve paramet

Antwort: Re: Support for ECParameters with explicit (not named) parameter spec

2017-12-06 Thread Max Fichtelmann
We use a HSM to generate ECDSA Keys and are required to use the curve brainpoolP256r1. Although the HSM does not specifically support brainpool, it is possible to generate these keys by providing the specific Curve Parameters. These curve parameters are then saved in CKA_EC_PARAMS - the PKCS11

Re: [PATCH] JDK-8190917 : SSL session resumption, through handshake, in SSLEngine is broken for any protocols lesser than TLSv1.2

2017-12-06 Thread Jaikiran Pai
Thank you Xuelei. Please take your time. -Jaikiran On Wednesday, December 6, 2017, Xuelei Fan wrote: > Hi Jaikiran, > > I will sponsor this contribution. I need more time for the review and > testing. > > Thanks, > Xuelei > > On 11/23/2017 9:22 PM, Jaikiran Pai wrote: > >> As noted in [1], t

Re: Support for ECParameters with explicit (not named) parameter spec

2017-12-06 Thread Xuelei Fan
On 12/6/2017 4:24 AM, Max Fichtelmann wrote: Hello, currently sun.security.util.ECParameters.engineInit(byte[]) is limited to parse named curves. A commented block outlining parsing of explicit parameters is included below throwing "only named ECParameters supported". That comment block seems

Re: [PATCH] JDK-8190917 : SSL session resumption, through handshake, in SSLEngine is broken for any protocols lesser than TLSv1.2

2017-12-06 Thread Xuelei Fan
Hi Jaikiran, I will sponsor this contribution. I need more time for the review and testing. Thanks, Xuelei On 11/23/2017 9:22 PM, Jaikiran Pai wrote: As noted in [1], there's a regression in Java 9, where SSL session resumption no longer works for SSL protocols other than TLSv1.2. The code

Re: Support for ECParameters with explicit (not named) parameter spec

2017-12-06 Thread Adam Petcher
On 12/6/2017 7:24 AM, Max Fichtelmann wrote: Hello, currently sun.security.util.ECParameters.engineInit(byte[]) is limited to parse named curves. A commented block outlining parsing of explicit parameters is included below throwing "only named ECParameters supported". That comment block seem

Support for ECParameters with explicit (not named) parameter spec

2017-12-06 Thread Max Fichtelmann
Hello, currently sun.security.util.ECParameters.engineInit(byte[]) is limited to parse named curves. A commented block outlining parsing of explicit parameters is included below throwing "only named ECParameters supported". That comment block seems to be unchanged from at least jdk6 up until j

Re: RFR: 8185855: Debug exception stacks should be clearer

2017-12-06 Thread Seán Coffey
whoops - pasted the wrong file diffs in last email : diff --git a/src/java.base/share/classes/sun/security/util/AnchorCertificates.java b/src/java.base/share/classes/sun/security/util/AnchorCertificates.java --- a/src/java.base/share/classes/sun/security/util/AnchorCertificates.java +++ b/src/

Re: RFR: 8185855: Debug exception stacks should be clearer

2017-12-06 Thread Seán Coffey
Thanks for reviewing Sean. Not finding the cacerts file has always resulted in the stacktrace going to stderr in the past. I guess there's no harm putting it behind a debug flag. New diff for that file below. I'll push later today if I hear nothing else. diff --git a/src/java.base/share/class