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

[Prasadrao Koppula]

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 fixes on renewable

Change looks fine, but the code style of lines 947-954 is quite different from 
normal, including, no space after keywords, wrong indentation of inner block 
and wrapped line, brace and else not on the same line, etc.

--Max

> On Sep 19, 2018, at 10:40 PM, Prasadrao Koppula 
>  wrote:
> 
> Could you please review the following fixes for 8u-dev?
>  
> jbs: https://bugs.openjdk.java.net/browse/JDK-8187218, 
>https://bugs.openjdk.java.net/browse/JDK-8131051
> webrev: http://cr.openjdk.java.net/~pkoppula/8187218/webrev.00/
>  
> Thanks,
> Prasad.K

Re: RFR: JDK-8210846, TLSv.1.3 interop problems with OpenSSL 1.1.1 when used on the client side with mutual auth

[Jamil Nimeh]

Great news!  Thanks for running the tests on your end, Norman.


--Jamil

 Original message 
From: Norman Maurer  
Date: 9/19/18  4:32 PM  (GMT-08:00) 
To: Bradford Wetmore  
Cc: Jamil Nimeh , OpenJDK Dev list 
 
Subject: Re: RFR: JDK-8210846, TLSv.1.3 interop problems with OpenSSL 1.1.1
 when used on the client side with mutual auth 

I can confirm that this patch fixes the issue I was seeing. After applying it 
it also passes all of the tests that we have in the SSL testsuite of netty.

So +1 from me.

Bye
Norman


> On 19. Sep 2018, at 15:13, Bradford Wetmore  
> wrote:
> 
> Looks good from a CR standpoint.  Silly typos...
> 
> Looking forward to hearing back from Norman.  I believe we are running the 
> same testbed, so I expect it will work.
> 
> Jamil, be sure to include the specific interop test information in the bug, 
> so that when SQE goes to verify, they can be sure to run it manually.
> 
> Brad
> 
> 
> On 9/19/2018 1:59 PM, Norman Maurer wrote:
>> I will test and report back later today . Thanks for the quick turnaround
>>> Am 19.09.2018 um 13:47 schrieb Jamil Nimeh :
>>> 
>>> Hello all,
>>> 
>>> This fix handles an issue in TLS client certificate authentication where 
>>> our client was failing to send a certificate after consuming the 
>>> CertificateRequest message.  Thanks to Norman Maurer for bringing this to 
>>> our attention.
>>> 
>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210846/webrev.01/
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210846
>>> 
>>> --Jamil
>>> 

Re: RFR: JDK-8210846, TLSv.1.3 interop problems with OpenSSL 1.1.1 when used on the client side with mutual auth

[Norman Maurer]

I can confirm that this patch fixes the issue I was seeing. After applying it 
it also passes all of the tests that we have in the SSL testsuite of netty.

So +1 from me.

Bye
Norman


> On 19. Sep 2018, at 15:13, Bradford Wetmore  
> wrote:
> 
> Looks good from a CR standpoint.  Silly typos...
> 
> Looking forward to hearing back from Norman.  I believe we are running the 
> same testbed, so I expect it will work.
> 
> Jamil, be sure to include the specific interop test information in the bug, 
> so that when SQE goes to verify, they can be sure to run it manually.
> 
> Brad
> 
> 
> On 9/19/2018 1:59 PM, Norman Maurer wrote:
>> I will test and report back later today . Thanks for the quick turnaround
>>> Am 19.09.2018 um 13:47 schrieb Jamil Nimeh :
>>> 
>>> Hello all,
>>> 
>>> This fix handles an issue in TLS client certificate authentication where 
>>> our client was failing to send a certificate after consuming the 
>>> CertificateRequest message.  Thanks to Norman Maurer for bringing this to 
>>> our attention.
>>> 
>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210846/webrev.01/
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210846
>>> 
>>> --Jamil
>>> 

Re: RFR: JDK-8210846, TLSv.1.3 interop problems with OpenSSL 1.1.1 when used on the client side with mutual auth

[Jamil Nimeh]

I will add my test information to the bug.  Thanks for reviewing it.


--Jamil
 Original message From: Bradford Wetmore 
 Date: 9/19/18  3:13 PM  (GMT-08:00) To: Norman 
Maurer , Jamil Nimeh  
Cc: OpenJDK Dev list  Subject: Re: RFR: 
JDK-8210846, TLSv.1.3 interop problems with OpenSSL 1.1.1 when used on the 
client side with mutual auth 
Looks good from a CR standpoint.  Silly typos...

Looking forward to hearing back from Norman.  I believe we are running 
the same testbed, so I expect it will work.

Jamil, be sure to include the specific interop test information in the 
bug, so that when SQE goes to verify, they can be sure to run it manually.

Brad


On 9/19/2018 1:59 PM, Norman Maurer wrote:
> I will test and report back later today . Thanks for the quick turnaround
> 
>> Am 19.09.2018 um 13:47 schrieb Jamil Nimeh :
>>
>> Hello all,
>>
>> This fix handles an issue in TLS client certificate authentication where our 
>> client was failing to send a certificate after consuming the 
>> CertificateRequest message.  Thanks to Norman Maurer for bringing this to 
>> our attention.
>>
>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210846/webrev.01/
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210846
>>
>> --Jamil
>>

Re: RFR: JDK-8210846, TLSv.1.3 interop problems with OpenSSL 1.1.1 when used on the client side with mutual auth

[Bradford Wetmore]

Looks good from a CR standpoint.  Silly typos...

Looking forward to hearing back from Norman.  I believe we are running 
the same testbed, so I expect it will work.


Jamil, be sure to include the specific interop test information in the 
bug, so that when SQE goes to verify, they can be sure to run it manually.


Brad


On 9/19/2018 1:59 PM, Norman Maurer wrote:

I will test and report back later today . Thanks for the quick turnaround


Am 19.09.2018 um 13:47 schrieb Jamil Nimeh :

Hello all,

This fix handles an issue in TLS client certificate authentication where our 
client was failing to send a certificate after consuming the CertificateRequest 
message.  Thanks to Norman Maurer for bringing this to our attention.

Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210846/webrev.01/

JBS: https://bugs.openjdk.java.net/browse/JDK-8210846

--Jamil

Re: RFR: JDK-8210846, TLSv.1.3 interop problems with OpenSSL 1.1.1 when used on the client side with mutual auth

[Norman Maurer]

I will test and report back later today . Thanks for the quick turnaround

> Am 19.09.2018 um 13:47 schrieb Jamil Nimeh :
> 
> Hello all,
> 
> This fix handles an issue in TLS client certificate authentication where our 
> client was failing to send a certificate after consuming the 
> CertificateRequest message.  Thanks to Norman Maurer for bringing this to our 
> attention.
> 
> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210846/webrev.01/
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8210846
> 
> --Jamil
> 

RFR: JDK-8210846, TLSv.1.3 interop problems with OpenSSL 1.1.1 when used on the client side with mutual auth

[Jamil Nimeh]

Hello all,

This fix handles an issue in TLS client certificate authentication where 
our client was failing to send a certificate after consuming the 
CertificateRequest message.  Thanks to Norman Maurer for bringing this 
to our attention.


Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210846/webrev.01/

JBS: https://bugs.openjdk.java.net/browse/JDK-8210846

--Jamil

Re: Conceptual feedback on new ECC JEP

[Adam Petcher]

On 9/19/2018 1:37 PM, Bernd Eckenfels wrote:

Hello,

I think I missed it, but where is the conversion on BigInteger 
branching on key material? Isn’t this only branching on effective 
constant values?


Or are you concerned about Spectre-type problems?


This is not for Spectre (etc.) issues, which effectively dump all memory 
contents, so there is nothing we can do to prevent it at this level. The 
proposed implementation defends against cache attacks like 
Flush+Reload[1], as well as timing attacks.


Imagine an EC private key (i.e. a scalar) is stored in a fixed-length 
little-endian byte array in the key implementation class. I can perform 
the required EC operations directly on this byte array without branching 
on any part of its value. Now if I want to convert this key to an 
ECPrivateKeySpec using the KeyFactory, I need to convert this scalar to 
a BigInteger, which uses a variable-length representation. This 
conversion necessarily branches on the value of the private key, which 
we are trying to avoid.


Branching on any non-secret value (including algorithm parameters and 
constants) is fine, but in the example above, we would be branching on 
the valud of the private key.


[1] https://eprint.iacr.org/2013/448.pdf



Besides that I totally agree on the idea of having a more secure 
implementation which can be activated by simply switching provider 
priorities.


Gruss
Bernd

Re: Conceptual feedback on new ECC JEP

[Adam Petcher]

On 9/19/2018 12:51 PM, Michael StJohns wrote:


On 9/19/2018 11:45 AM, Adam Petcher wrote:
My goal is for the new provider to be at least as interoperable as 
PKCS11 providers with non-exportable keys. Do all the PKCS11 
providers that you have used allow importing private keys over JCA, 
or over some other API? Do you have to put the HSM in some sort of 
"import mode" in order for this import to be allowed? Is there any 
difference in the way that you can use keys that were loaded over 
this API vs keys that were generated on the device (or loaded securely)?



Again - you seriously want to hang your hat on this?:

1) Yes.  Over the JCA.  (Umm.. PKCS11 provider is a JCA/JCE provider 
so of course this works).


2) No.  In fact, the store operation of the PKCS11 keystore 
implementation does this just fine.


3) Depends.  If you generate or load the HSM PKCS11 keys according to 
the JCA PKCS11 guidance (e.g. with the right set of attributes) using 
a direct PKCS11 driver, then it's seamless. Otherwise, the Sun PKCS11 
keystore implementation mostly ignores them as it can't map them 
properly.    I'd need to check the other two providers I'm aware of, 
but I think they implement the same scheme as the Sun provider.  
There's also a scheme for twiddling the attributes as part of the 
provider configuration, but that's a bit more painful.


See 
https://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html 
and Appendix B.





Thanks for the information. I'm having trouble believing that there is 
no situation in which a PKCS11 provider/token/HSM would reject a key 
that it is asked to import. But this is mostly a detour in the 
discussion. If the API of the new ECC implementation is, in some ways, 
more restrictive than PKCS11 with non-extractable keys, then that is 
acceptable to me.

Re: Conceptual feedback on new ECC JEP

[Bernd Eckenfels]

Hello,

I think I missed it, but where is the conversion on BigInteger branching on key 
material? Isn’t this only branching on effective constant values?

Or are you concerned about Spectre-type problems?

Besides that I totally agree on the idea of having a more secure implementation 
which can be activated by simply switching provider priorities.

Gruss
Bernd

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: -1001833328m Auftrag von
Gesendet: Mittwoch, September 19, 2018 7:16 PM
An: security-dev@openjdk.java.net
Betreff: Re: Conceptual feedback on new ECC JEP

On 9/18/2018 4:24 PM, Michael StJohns wrote:

>
> Adam -
>
> Basically, the JCE is all about plugging in not about the
> implementations.  If this is truly an EC library, I should be able to
> get the benefit of your library with very minimal changes - e.g.
> specifying your provider in the various getInstance() calls.   As it
> stands, I doubt this will end up in anyone's "must use" category
> because it will break existing code.

Is this standard of being "truly an EC library" met by PKCS11 providers
that don't export keys?

>
> You want folks to convince you that interoperability is a significant
> problem when what we (or at least I) want is for you to convince us
> that these interop breaks are warranted due to how wonderful your
> approach is and that they're absolutely necessary due the secret sauce
> of wonderfulness.  You're not there yet.

I don't agree with this logic. Different providers have different levels
of interoperability, and this interoperability is a feature that
requires effort to develop and maintain. I don't want to commit myself
or this community to this effort unless I/we think it is worthwhile.
Some of the proposals to increase interoperability for this effort (e.g.
subclassing BigInteger) would require a significant amount of additional
effort, and I think this requires justification.

Of course, if you know of a way to have more interoperability without
reducing assurance or significantly increasing effort, I would love to
hear about it. For assurance, an important property is that the
implementation should not branch on secrets after the developer has put
it in branchless mode (by selecting the branchless provider or by using
some other interface to switch modes).

>
> As for PKCS11 - there are exportable and non-exportable private keys
> (e.g. PKCS11 with an accelerator vs an HSM for example).  The
> exportable ones show up as ECPrivateKeys, the non-exportable ones as
> PrivateKeys (and I think with an underlying type of PKCS11Key...).  So
> it follows the model for exportable keys.  And every PKCS11 provider
> I've used at least has a way of IMPORTING ECPrivateKeys.

My goal is for the new provider to be at least as interoperable as
PKCS11 providers with non-exportable keys. Do all the PKCS11 providers
that you have used allow importing private keys over JCA, or over some
other API? Do you have to put the HSM in some sort of "import mode" in
order for this import to be allowed? Is there any difference in the way
that you can use keys that were loaded over this API vs keys that were
generated on the device (or loaded securely)?

Re: Conceptual feedback on new ECC JEP

[Michael StJohns]

On 9/19/2018 11:45 AM, Adam Petcher wrote:

On 9/18/2018 4:24 PM, Michael StJohns wrote:



Adam -

Basically, the JCE is all about plugging in not about the 
implementations.  If this is truly an EC library, I should be able to 
get the benefit of your library with very minimal changes - e.g. 
specifying your provider in the various getInstance() calls.   As it 
stands, I doubt this will end up in anyone's "must use" category 
because it will break existing code.


Is this standard of being "truly an EC library" met by PKCS11 
providers that don't export keys?


This is what you want to hang your hat on?   If you want to implement 
your code inside an HSM and follow the PKCS11 rules, feel free.  
Software libraries are not hardware libraries and the mapping between 
them is pretty good, but not perfect.


And to be clear, it's not the provider that doesn't export the keys - 
its the underlying HSM and not for all keys.  It's perfectly OK to 
generate an exportable key on an HSM, but the usual default is the roach 
motel model.  The provider humors this reality by following the various 
interface contracts and only providing a PrivateKey object for 
non-exportable private keys, regardless of type.






You want folks to convince you that interoperability is a significant 
problem when what we (or at least I) want is for you to convince us 
that these interop breaks are warranted due to how wonderful your 
approach is and that they're absolutely necessary due the secret 
sauce of wonderfulness.  You're not there yet.


I don't agree with this logic. 


Color me surprised.

Different providers have different levels of interoperability, 
No - different providers mostly provide different suites of crypto, but 
build to a well-defined interface or set of interfaces.   E.g. I really 
don't give a damn about what you do inside your own country, but you 
need to have the same type of passport as everyone else once you leave 
those boundaries.



and this interoperability is a feature that requires effort to develop 
and maintain. I don't want to commit myself or this community to this 
effort unless I/we think it is worthwhile. Some of the proposals to 
increase interoperability for this effort (e.g. subclassing 
BigInteger) would require a significant amount of additional effort, 
and I think this requires justification.


Implementing to a defined interface is somewhat different than 
"maintaining interoperability" - at least if you do it right. AFAICT, 
you're balking at providing the getS() method of the ECPrivateKey 
interface because you're afraid that conversion to/from BigInteger will 
leak something.  Guess what... any time you border cross you leak 
something.  Even
 moving key material from software to hardware will cause you to leak 
something.





Of course, if you know of a way to have more interoperability without 
reducing assurance or significantly increasing effort, I would love to 
hear about it. For assurance, an important property is that the 
implementation should not branch on secrets after the developer has 
put it in branchless mode (by selecting the branchless provider or by 
using some other interface to switch modes).


*bleah*  This is not a useful discussion - you've drawn a line in the 
sand without actually understanding the cost/benefit of that line.   And 
I gave you several approaches - simplest is to clone BigInteger and 
de-branch it for the methods you need.  Actually, simplest is to use the 
existing BigInteger, because if the provider user is exporting the key 
material, they're probably going to be putting it into a whole different 
provider with "weaker" branchless protections.






As for PKCS11 - there are exportable and non-exportable private keys 
(e.g. PKCS11 with an accelerator vs an HSM for example). The 
exportable ones show up as ECPrivateKeys, the non-exportable ones as 
PrivateKeys (and I think with an underlying type of PKCS11Key...).  
So it follows the model for exportable keys. And every PKCS11 
provider I've used at least has a way of IMPORTING ECPrivateKeys.


My goal is for the new provider to be at least as interoperable as 
PKCS11 providers with non-exportable keys. Do all the PKCS11 providers 
that you have used allow importing private keys over JCA, or over some 
other API? Do you have to put the HSM in some sort of "import mode" in 
order for this import to be allowed? Is there any difference in the 
way that you can use keys that were loaded over this API vs keys that 
were generated on the device (or loaded securely)?



Again - you seriously want to hang your hat on this?:

1) Yes.  Over the JCA.  (Umm.. PKCS11 provider is a JCA/JCE provider so 
of course this works).


2) No.  In fact, the store operation of the PKCS11 keystore 
implementation does this just fine.


3) Depends.  If you generate or load the HSM PKCS11 keys according to 
the JCA PKCS11 guidance (e.g. with the right set of attributes) using a 
direct PKCS11 driver, then it's 

Re: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth

[Xuelei Fan]

Hi Norman,

It is just a initial version set.

Thanks,
Xuelei

On 9/19/2018 8:49 AM, Norman Maurer wrote:
I see this is now tracked as 
https://bugs.openjdk.java.net/projects/JDK/issues/JDK-8210846?filter=allopenissues :)


Just one question, I saw it list 12 as fix version. Is this just the 
initial version set or do you not plan to fix it in Java11 ? IMHO this 
is a quite an important thing to fix as otherwise you may run into 
issues when using SSL on the client-side as most real-world apps use 
OpenSSL on the server-side.


Bye
Norman


On 17. Sep 2018, at 10:44, Norman Maurer > wrote:


Of course not…

ID: 9057280

Thanks
Norman


On 17. Sep 2018, at 19:35, Xuelei Fan > wrote:


Hi Norman,

Thank you so much for the reproducing code.  Would you mind file a 
bug for this issue?


Thanks,
Xuelei

On 9/17/2018 3:39 AM, Norman Maurer wrote:

Hi all,
As requested I pushed a pure JDK reproducer to GitHub which you can 
easily use to reproduce the problem. All the details how to run it 
etc are in the README.md file. I also included a server to show that 
all works if we use the JDK on the client side and server side.
Also as stated before you will see that the cert will be send even 
if you use OpenSSL on the serverside if you replace “-Verify 1” with 
“-verify 1” (which is kind of the same as setWantClientAuth(true)).
Please don't hesitate to ping me if you need any more details or 
have any more questions.

https://github.com/normanmaurer/jdktls13bugreproducer
Here is the output with debugging enabled on the client side.
javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.515 
CEST|SSLContextImpl.java:427|System property 
jdk.tls.client.cipherSuites is set to 'null'
javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.529 
CEST|SSLContextImpl.java:427|System property 
jdk.tls.server.cipherSuites is set to 'null'
javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.563 
CEST|SSLCipher.java:437|jdk.tls.keyLimits:  entry = 
AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 
137438953472
javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.577 
CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: 
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.577 
CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: 
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 
CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: 
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.578 
CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: 
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 
CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: 
SSL_RSA_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.578 
CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: 
SSL_RSA_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 
CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: 
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 
CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: 
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.579 
CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: 
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 
CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: 
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.579 
CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: 
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 
CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: 
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.580 
CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: 
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.580 
CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: 
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 
CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: 
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.581 
CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: 
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 
CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: 
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.581 
CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: 
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 
CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: 
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 
CEST|SSLContextImpl.java:410|Ignore 

Re: RFR(XS): 8210912: Build error in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c after JDK-8029661

[Mikael Vidstedt]

Thank you! Change pushed and noreg-build label added.

Cheers,
Mikael

> On Sep 19, 2018, at 9:13 AM, Sean Mullan  wrote:
> 
> Looks ok to me. The bug needs an appropriate noreg label.
> 
> --Sean
> 
> On 9/19/18 12:05 PM, Mikael Vidstedt wrote:
>> Please review this change which fixes a Solaris/SPARC build issue:
>> bug: https://bugs.openjdk.java.net/browse/JDK-8210912
>> webrev: 
>> http://cr.openjdk.java.net/~mikael/webrevs/8210912/webrev.00/open/webrev/ 
>> 
>> Testing:
>> Tier1 test job (still in progress, but relevant builds passed).
>> Cheers,
>> Mikael

Re: RFR(XS): 8210912: Build error in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c after JDK-8029661

[Sean Mullan]

Looks ok to me. The bug needs an appropriate noreg label.

--Sean

On 9/19/18 12:05 PM, Mikael Vidstedt wrote:


Please review this change which fixes a Solaris/SPARC build issue:

bug: https://bugs.openjdk.java.net/browse/JDK-8210912
webrev: 
http://cr.openjdk.java.net/~mikael/webrevs/8210912/webrev.00/open/webrev/ 


Testing:

Tier1 test job (still in progress, but relevant builds passed).

Cheers,
Mikael

RFR(XS): 8210912: Build error in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c after JDK-8029661

[Mikael Vidstedt]

Please review this change which fixes a Solaris/SPARC build issue:

bug: https://bugs.openjdk.java.net/browse/JDK-8210912 

webrev: 
http://cr.openjdk.java.net/~mikael/webrevs/8210912/webrev.00/open/webrev/ 


Testing:

Tier1 test job (still in progress, but relevant builds passed).

Cheers,
Mikael

Re: Conceptual feedback on new ECC JEP

[Adam Petcher]

On 9/18/2018 4:24 PM, Michael StJohns wrote:



Adam -

Basically, the JCE is all about plugging in not about the 
implementations.  If this is truly an EC library, I should be able to 
get the benefit of your library with very minimal changes - e.g. 
specifying your provider in the various getInstance() calls.   As it 
stands, I doubt this will end up in anyone's "must use" category 
because it will break existing code.


Is this standard of being "truly an EC library" met by PKCS11 providers 
that don't export keys?




You want folks to convince you that interoperability is a significant 
problem when what we (or at least I) want is for you to convince us 
that these interop breaks are warranted due to how wonderful your 
approach is and that they're absolutely necessary due the secret sauce 
of wonderfulness.  You're not there yet.


I don't agree with this logic. Different providers have different levels 
of interoperability, and this interoperability is a feature that 
requires effort to develop and maintain. I don't want to commit myself 
or this community to this effort unless I/we think it is worthwhile. 
Some of the proposals to increase interoperability for this effort (e.g. 
subclassing BigInteger) would require a significant amount of additional 
effort, and I think this requires justification.


Of course, if you know of a way to have more interoperability without 
reducing assurance or significantly increasing effort, I would love to 
hear about it. For assurance, an important property is that the 
implementation should not branch on secrets after the developer has put 
it in branchless mode (by selecting the branchless provider or by using 
some other interface to switch modes).




As for PKCS11 - there are exportable and non-exportable private keys 
(e.g. PKCS11 with an accelerator vs an HSM for example).  The 
exportable ones show up as ECPrivateKeys, the non-exportable ones as 
PrivateKeys (and I think with an underlying type of PKCS11Key...).  So 
it follows the model for exportable keys.  And every PKCS11 provider 
I've used at least has a way of IMPORTING ECPrivateKeys.


My goal is for the new provider to be at least as interoperable as 
PKCS11 providers with non-exportable keys. Do all the PKCS11 providers 
that you have used allow importing private keys over JCA, or over some 
other API? Do you have to put the HSM in some sort of "import mode" in 
order for this import to be allowed? Is there any difference in the way 
that you can use keys that were loaded over this API vs keys that were 
generated on the device (or loaded securely)?

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

[Weijun Wang]

Change looks fine, but the code style of lines 947-954 is quite different from 
normal, including, no space after keywords, wrong indentation of inner block 
and wrapped line, brace and else not on the same line, etc.

--Max

> On Sep 19, 2018, at 10:40 PM, Prasadrao Koppula 
>  wrote:
> 
> Could you please review the following fixes for 8u-dev?
>  
> jbs: https://bugs.openjdk.java.net/browse/JDK-8187218, 
>https://bugs.openjdk.java.net/browse/JDK-8131051
> webrev: http://cr.openjdk.java.net/~pkoppula/8187218/webrev.00/
>  
> Thanks,
> Prasad.K

Re: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider

[Martin Balao]

On Wed, Sep 19, 2018 at 1:52 AM, Valerie Peng 
wrote:

> Test update looks fine and regression test run is clear. I have no more
> comments.
> Thanks,
> Valerie
>

Submit-repository tests passed.

Integrated to baseline then:

 * http://hg.openjdk.java.net/jdk/jdk/rev/bccd9966f1ed

Thanks Valerie for your review :-)

I'll propose JDK8 and JDK7 backports now.

Kind regards,
Martin.-