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

2018-01-31 Thread Valerie Peng 

Hi Martin,

Thanks for providing us with the patch. Recently, JDK workspace has been 
restructured a bit, do you have an updated webrev?


Your changes mostly look fine, but I think we should allow 3rd party 
providers to have similar support. For this, we need to have more public 
APIs such as those classes under sun.security.internal.spec package and 
possibly more. What do you think?


Thanks,
Valerie

On 11/10/2017 6:38 AM, Martin Balao wrote:

Hi,

I would like to propose a patch for JDK-8029661: JDK-Support TLS v1.2 
algorithm in SunPKCS11 provider [1].


 * 
http://cr.openjdk.java.net/~akasko/mbalao/jdk_8029661_tls_12_sunpkcs11/2017_11_09/8029661.webrev.01/ 
 
(browse online)
 * 
http://cr.openjdk.java.net/~akasko/mbalao/jdk_8029661_tls_12_sunpkcs11/2017_11_09/8029661.webrev.01.zip 
 
(download)


The following algorithms have been implemented in SunPKCS11 provider 
(based on PKCS#11 v2.40 mechanisms):


 * SunTls12RsaPremasterSecret
 * SunTls12MasterSecret
 * SunTls12KeyMaterial
 * SunTls12Prf

A minor API change is proposed to expose TLS ProtocolVersion constants 
(SSL30, TLS10, TLS11, etc.) from java.base to jdk.crypto.cryptoki 
module. This allows to remove hardcoded TLS int constants in SunPKCS11 
classes (required when implementing "Tls"-like algorithms).


A test case is included with the following:

 * TLS 1.2 communication using SunPKCS11 + NSS (in FIPS mode)
 * Algorithms test against SunJCE

Regards,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8029661

Re: PKCS#11 provider issues with min and max size

2018-01-31 Thread Valerie Peng 


Thanks for the feedback. I suppose we can ignore values which obviously 
don't make sense such as 0 or max being less than min key size.
However, if the underlying PKCS11 library vendors forgot to update the 
max value as in your comment#2, supposedly they should fix it.
I am not too keen to add an env var/system property to accommodate this 
kind of PKCS11 library bugs since this should be rare I hope.

Valerie

On 1/30/2018 12:22 AM, Tomas Gustavsson wrote:

Hi,

At some revision in the PKCS#11 provider there was introduced checking
of C_GetMechanismInfo min and max sizes.

This has turned out to be a bit fragile. Let me give two real world
examples:

1. Amazon Cloud HSM report minSize and maxSize for EC keys to 0. The
Java PKCS#11 provider will happily take 0 as maxSize and refuse to
generate any EC keys at all. Needless to say, without the Java check it
would be no problem.

131: C_GetMechanismInfo
2018-01-30 07:52:20.740
[in] slotID = 0x1
  CKM_EC_KEY_PAIR_GEN
[out] pInfo:
CKM_EC_KEY_PAIR_GEN   : min:0 max:0 flags:0x10001 ( Hardware
KeyPair )
Returned:  0 CKR_OK

(we are reporting this to Amazon as well)

2. Thales HSMs (some?) report maxSize for RSA_PKCS key generation as
4096, but will happily generate 8192 bit keys. I.e. the reported maxSize
is not true.
We have customers who used to generate 8192 bit RSA keys, but after a
Java update can not do so anymore, because Java compares against this value.


* Suggestions:

1. In the constructor of P11KeyPairGenerator where minKeyLen and
maxKeyLen are calculated, never allow maxKeyLen to be less than minKeyLen.

I.e. change the part:
 // auto-adjust default keysize in case it's out-of-range
 if ((minKeyLen != -1) && (keySize < minKeyLen)) {
 keySize = minKeyLen;
 }
 if ((maxKeyLen != -1) && (keySize > maxKeyLen)) {
 keySize = maxKeyLen;
 }

To include something like:
 // auto-adjust default keysize in case it's out-of-range
 if ((minKeyLen != -1) && (keySize < minKeyLen)) {
 keySize = minKeyLen;
 }
 if ((maxKeyLen != -1) && (maxKeyLen < minKeyLen)) {
 maxKeyLen = minKeyLen;
 }
 if ((maxKeyLen != -1) && (keySize > maxKeyLen)) {
 keySize = maxKeyLen;
 }

2. Allow to ignore checking of maxKeyLen by some means, i.e. allow to
ignore checking against C_GetMechanismInfo if you know that the HSM does
not provide sane values. I.e. an environment variable for example
reverting back to the old behavior when these were ignored.

Regards,
Tomas Gustavsson

Re: Webservice error - 2 counts of InaccessibleWSDLException - due to JDK update from 112 to 121

2018-01-31 Thread Sean Mullan 


On 1/24/18 5:36 AM, Patrick Goovaerts wrote:

Hi,

After updating JKD 1.8.0 from u112 to u121, i get errors executing 
webservices which uses a certificate.


The error I get is: 
com.sun.xml.internal.ws.wsdl.parser.InaccessibleWSDLException: 2 counts 
of InaccessibleWSDLException


In the example I ran the code with u152 but same prob occurs as from u121

Anyone who could help me with this?


Not sure, but can you get a more complete stack trace which would show 
the underlying cause of the NoSuchAlgorithmException?


You could also try adding -Djava.security.debug=all 
-Djavax.net.debug=all to your command line to see if anything 
interesting comes up in the debug messages.


Also, this is not a support forum, but hopefully those tips above will 
get you on the right track. If you are still having trouble and can come 
up with a reproducible test case that we can run, you can file a bug at 
https://bugreport.java.com/


--Sean





PC - COMMAND PROMPT - JAVA 1_8_00152



C:\Data\Kantoor\WebServices\PLDA>"C:\Program Files\Java\jdk8\bin\java" 
-version


java version "1.8.0_152"

Java(TM) SE Runtime Environment (build 1.8.0_152-b16)

Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode)

C:\Data\Kantoor\WebServices\PLDA>"C:\Program Files\JAVA\jdk8\bin\java" 
-cp WS-Clients.jar;Conti7.jar;Conti7Utilities.jar 
com.clipper.ws.clients.Plda


2018-01-23 21:39:06.559 com.clipper.ws.clients.Plda 
Plda(keyStore=C:/Data/kantoor/WebServices/PLDA/PGO_Conti71619.pfx, 
keyStoreType=pkcs12, keyStorePwd=Conti7Sp0rtlife): Creating WebService 
Plda object...


2018-01-23 21:39:06.576 com.clipper.ws.clients.Plda Create 
PldaWebwervice_Service(): Creating Service


Exception in thread "main" 
com.sun.xml.internal.ws.wsdl.parser.InaccessibleWSDLException: 2 counts 
of InaccessibleWSDLException.


java.net.SocketException: java.security.NoSuchAlgorithmException: Error 
constructing implementation (algorithm: Default, provider: SunJSSE, 
class: sun.security.ssl.SSLContextImpl$DefaultSSLContext)


java.net.SocketException: java.security.NoSuchAlgorithmException: Error 
constructing implementation (algorithm: Default, provider: SunJSSE, 
class: sun.security.ssl.SSLContextImpl$DefaultSSLContext)


     at 
com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.tryWithMex(RuntimeWSDLParser.java:260)


     at 
com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:231)


     at 
com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:194)


     at 
com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:163)


     at 
com.sun.xml.internal.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:348)


     at 
com.sun.xml.internal.ws.client.WSServiceDelegate.(WSServiceDelegate.java:306)


     at 
com.sun.xml.internal.ws.client.WSServiceDelegate.(WSServiceDelegate.java:215)


     at 
com.sun.xml.internal.ws.client.WSServiceDelegate.(WSServiceDelegate.java:196)


     at 
com.sun.xml.internal.ws.client.WSServiceDelegate.(WSServiceDelegate.java:192)


     at 
com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)


     at javax.xml.ws.Service.(Service.java:77)

     at 
com.clipper.ws.plda.PldaWebservice_Service.(PldaWebservice_Service.java:51)


     at com.clipper.ws.clients.Plda.(Plda.java:30)

     at com.clipper.ws.clients.Plda.main(Plda.java:80)

*Patrick Goovaerts*

**