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

[Martin Balao]

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.-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20180205/3a17091b/attachment.htm>