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

Martin Balao mbalao at redhat.com
Tue May 22 20:27:08 UTC 2018

Hi Valerie,

Webrev 03 with changes to TestTLS12.java is here:

 * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.03
 * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.03.zip

The reason why we need a dependency to sun.security.pkcs11.SunPKCS11 is to
instance such provider in run time with a custom configuration -instead of
getting one with a configuration from java.security-. In this particular
case, I'm interested in the SunPKCS11 provider to be FIPS -as this
reproduces a real case-. Other SunPKCS11 tests have this dependency too, as
you can see in PKCS11Test class [1]. This dependency sounds reasonable to
me, as we are developing a SunPKCS11 test. However, if you see a different
way of doing this and removing this dependency, I'd be glad to remove it.

NSS hardcoded paths and SunPKCS11 instance creation removed leveraging on
PKCS11Test machinery. sun.security.pkcs11.SunPKCS11 dependency is now
indirect through PKCS11Test. Existing FIPS certificates (in
test/jdk/sun/security/pkcs11/fips) are not suitable for this test because
of the algorithms and expirity date. I can merge certificates and private
key files if you want.

Dependencies removed:
 * sun.security.rsa.RSAPrivateCrtKeyImpl
 * sun.security.rsa.RSAPublicKeyImpl
 * sun.security.ec.SunEC
 * sun.security.jca.ProviderList
 * java.io.ByteArrayInputStream
 * java.io.InputStream
 * java.lang.reflect.Constructor
 * java.nio.charset.StandardCharsets
 * sun.security.jca.Providers

Dependencies added:
 * PKCS11Test
 * java.security.interfaces.RSAPublicKey
 * java.security.spec.X509EncodedKeySpec
 * java.security.spec.PKCS8EncodedKeySpec
 * java.security.KeyFactory added.

White spaces on empty lines and unnecessary white spaces removed.

Regarding sun.security.internal.spec.TlsMasterSecretParameterSpec,
sun.security.internal.spec.TlsPrfParameterSpec and
sun.security.internal.spec.TlsRsaPremasterSecretParameterSpec dependencies,
test includes 2 assertions:

 1) Self-integrity assertion
  * A plain text message is transmitted over TLS 1.2 between 2 parties and
message integrity is verified at both endpoints
  * This is a functional test that uses public APIs.

 2) Cross-provider assertion
  * Keys for a TLS 1.2 communication are derived and asserted against a
well-known provider.

To do assertion 2), classes from SunJSSE are required. I think this
assertion adds value because the self-integrity test does not check that
negotiated keys are correct: comparing to a third-party provides more
guarantee. The reason why we are not comparing against fixed values is
because there are timestamps and random values involved and making them
fixed will require some more hacking. I agree with you that including
cross-package references on a unit test has a higher maintainance cost
-even when SunPKCS11 and TLS features are closely related-, but I suggest
to make an exception here given the value it provides.

Look forward to your answer.

Kind regards,

[1] -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20180522/80e925ae/attachment.html>

More information about the security-dev mailing list