Re: RFR: 8199018: Test crypto provider not registering

[Brad Wetmore]

Looks good.

This looks like it still needs to be done in jdk/jdk.  Are you planning 
on doing that?


Thanks,

Brad


On 3/5/2018 6:37 AM, Seán Coffey wrote:
Brad pointed out to me off-line that the test case from 8193892 needs 
correcting. Some late editing to the test broke functionality. I've 
corrected the testcase and added extra checks to ensure that 
"MyProvider" is being registered correctly.


https://bugs.openjdk.java.net/browse/JDK-8199018
http://cr.openjdk.java.net/~coffeys/webrev.8199018/webrev/

[PATCH]: Support for brainpool curves from CurveDB in SunEC

[Tobias Wagner]

Hi Valerie and Tomas,

thanks for the hint about SoftHSM. I just found the time to test it. I was 
able to run TestECDH using it with a SoftHSM2 based SunPKCS11 provider.

I did not hear anything about my last response - so I hope, this it might be 
helpful. I wonder if there is anything left to do for me or whether the 
proposed patch is acceptable as it is right now.

There is a patch attached to show the test setup - but this is nothing to be 
used in production. There is also the jtreg output for TestECDH with SoftHSM2

To run this, I had to do some things before
* Build SoftHSM2 myself. I've used this version: 
https://github.com/opendnssec/SoftHSMv2/releases/tag/2.4.0 . The versions 
available via
   package managers did not work for me
* Generate a new token 'softhsm2-util --init-token --slot 0 --label "Token 0"' 
with PIN '123456' for the Token an the SO as well

NOTE: The PIN is hard coded into the example patch.

This worked on Linux and MacOS.

Regards,
Tobias




Am 09.02.2018 um 10:22 schrieb Tomas Gustavsson:
>
> Just FYI. SoftHSM2 from the OpenDNSSec project is a good P11 to test
> with, and I believe it supports brainpool in recent versions.
> https://github.com/opendnssec/SoftHSMv2
>
> It works really good)
>
> Regards,
> Tomas
>
> On 2018-02-09 02:03, Valerie Peng wrote:
>> Hi Tobias,
>>
>> Just curious, which PKCS11 library did you use to test your patch? After
>> I applied your patch and ran the regression tests, I noticed that both
>> the Solaris PKCS11 library and NSS skipped testing Brainpool curves with
>> different error codes which may be due to lack of support...
>>
>> Regards,
>> Valerie


TestECDH.jtr
Description: Binary data


openjdk_jdk_49130.patch
Description: Binary data


smime.p7s
Description: S/MIME cryptographic signature

Re: RFR 8191139: Remove deprecated javax.security.auth.Policy API

[Sean Mullan]

On 3/4/18 10:44 PM, Weijun Wang wrote:

For the 3rd/4th ones above, there is still some code in 
sun.security.provider.PolicyFile that looks for it, so it can be removed as 
part of this change now. Can you remove that and send an updated webrev?

http://cr.openjdk.java.net/~weijun/8191139/webrev.01/  posted. I also removed 
the changes to the localized resources files. They should be maintained by the 
translation team.


Looks good.

--Sean

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

[Martin Balao]

Any updates on this?

Thanks,
Martin.-

On Thu, Feb 15, 2018 at 9:53 PM, Valerie Peng 
wrote:

>
> I am ok with the idea of putting the public API refactoring under a
> separate RFE.
> Let me apply your updated patch below and run existing regressions again.
> Thanks,
> Valerie
>
>
> On 2/5/2018 5:51 AM, Martin Balao wrote:
>
> Hi Valerie,
>
> Thanks for your review.
>
> Here it's the new webrev updated to the new repository structure. I've
> also updated the testcase to use the new @module jtreg feature:
>
>  * http://cr.openjdk.java.net/~akasko/mbalao/jdk_8029661_tls_
> 12_sunpkcs11/2018_02_02/8029661.webrev.02 (online)
>  * http://cr.openjdk.java.net/~akasko/mbalao/jdk_8029661_tls_
> 12_sunpkcs11/2018_02_02/8029661.webrev.02.zip (download)
>
> A few comments in regards to creating public APIs from
> sun.security.internal.spec classes.
>
> Classes in jdk/src/java.base/share/classes/sun/security/internal/spec:
>  * TlsKeyMaterialParameterSpec.java
>  * TlsMasterSecretParameterSpec.java
>  * TlsRsaPremasterSecretParameterSpec.java
>  * TlsKeyMaterialSpec.java
>  * TlsPrfParameterSpec.java
>
> Classes in jdk/src/java.base/share/classes/java/security/spec (which I
> assume would be the destination):
>  * AlgorithmParameterSpec.java
>  * ECGenParameterSpec.java
>  * InvalidParameterSpecException.java
>  * RSAOtherPrimeInfo.java
>  * DSAGenParameterSpec.java
>  * ECParameterSpec.java
>  * KeySpec.java
>  * ...
>
> TlsRsaPremasterSecretParameterSpec class contains information about min
> and max SSL/TLS version and, optionally, the pre-master encoded key. This
> information may be useful to any 3rd party class that implements a
> KeyGenerator to generate RSA pre-master secrets.
>
> TlsMasterSecretParameterSpec class contains information (client/server
> random, pre-master secret, hash algorithm, etc.) to generate a master
> secret from a pre-master secret.
>
> TlsKeyMaterialParameterSpec class contains information (client/server
> random, master secret, hash algorithm, etc.) to generate keys for a session
> from a master secret.
>
> TlsPrfParameterSpec class contains information (secret key, label, hash
> algorithm, etc.) to generate handshake authentication codes.
>
> TlsKeyMaterialSpec class contains information about session keys. This
> class inherits from SecretKey class.
>
> So, I agree with you: these parameters/specs may be used by a 3rd party
> and would be better to have them as public interfaces.
>
> However, I suggest to address that in a new ticket because:
>  * it is not strictly inherent to SunPKCS11 + TLS 1.2 support we are
> providing in the context of this ticket;
>  * it would be more clear both in tickets documentation and repository
> changeset;
>  * this refactoring is going to go through CSR, which SunPKCS11 + TLS 1.2
> support does not need; and,
>  * we should also evaluate how TLS 1.3 changes going to impact into this.
>
> Would splitting this into a new ticket work for you?
>
> Kind regards,
> Martin.-
>
>
>

RFR: 8199018: Test crypto provider not registering

[Seán Coffey]

Brad pointed out to me off-line that the test case from 8193892 needs 
correcting. Some late editing to the test broke functionality. I've 
corrected the testcase and added extra checks to ensure that 
"MyProvider" is being registered correctly.


https://bugs.openjdk.java.net/browse/JDK-8199018
http://cr.openjdk.java.net/~coffeys/webrev.8199018/webrev/

--
Regards,
Sean.