JEP260 -- Impact on SunPKCS11?
In the Devoxx presentation "Prepare for JDK9", the strategy for encapsulating "sun.* " packages is discussed. The class sun.security.SunPkcs11 is not listed on slide 16 ("Uses of JDK-internal APIs"), but as the rest of sun.security.* is listed as "Non-critical, no replacement planned", will this also be case for SunPKCS11? As far as I know there is no alternative security Provider for integrating with PKCS11 aside from rolling your own jni code or using vendor-specific apis. We rely on SunPKCS for interfacing with an HSM and belgian e-id smartcard. And even though we are aware that touching sun.* is frowned upon, first search hit on "java pkcs11" gives following page: https://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.htm... . With such elaborate documentation, you can't really blame devs to actually use this functionality :) . Is there an alternative to SunPKCS11 or am I overlooking something? Thanks for your response, Glen Vermeylen
Including the security-dev mailing list. -Chris. On 16/11/15 12:13, glen.vermeylen@telenet.be wrote:
In the Devoxx presentation "Prepare for JDK9", the strategy for encapsulating "sun.* " packages is discussed. The class sun.security.SunPkcs11 is not listed on slide 16 ("Uses of JDK-internal APIs"), but as the rest of sun.security.* is listed as "Non-critical, no replacement planned", will this also be case for SunPKCS11? As far as I know there is no alternative security Provider for integrating with PKCS11 aside from rolling your own jni code or using vendor-specific apis.
We rely on SunPKCS for interfacing with an HSM and belgian e-id smartcard. And even though we are aware that touching sun.* is frowned upon, first search hit on "java pkcs11" gives following page: https://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.htm... . With such elaborate documentation, you can't really blame devs to actually use this functionality :) .
Is there an alternative to SunPKCS11 or am I overlooking something?
Thanks for your response, Glen Vermeylen
Hello Glen, JCE providers are always accessed via the Java SE public APIs and not directly via sun.* implementation classes. In JDK 9, the SunPKCS11 provider continues to be accessible via those APIs. It’s implementation classes are present in the jdk.crypto.pkcs11 module. Thanks.
On 16 Nov 2015, at 15:21, Chris Hegarty <chris.hegarty@oracle.com> wrote:
Including the security-dev mailing list.
-Chris.
On 16/11/15 12:13, glen.vermeylen@telenet.be wrote:
In the Devoxx presentation "Prepare for JDK9", the strategy for encapsulating "sun.* " packages is discussed. The class sun.security.SunPkcs11 is not listed on slide 16 ("Uses of JDK-internal APIs"), but as the rest of sun.security.* is listed as "Non-critical, no replacement planned", will this also be case for SunPKCS11? As far as I know there is no alternative security Provider for integrating with PKCS11 aside from rolling your own jni code or using vendor-specific apis.
We rely on SunPKCS for interfacing with an HSM and belgian e-id smartcard. And even though we are aware that touching sun.* is frowned upon, first search hit on "java pkcs11" gives following page: https://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.htm... . With such elaborate documentation, you can't really blame devs to actually use this functionality :) .
Is there an alternative to SunPKCS11 or am I overlooking something?
Thanks for your response, Glen Vermeylen
Additionally, in JDK 9 we have added a new configure method to the java.security.Provider class that allows you to configure an underlying provider with an additional argument. The SunPKCS11 implementation has been enhanced to support this method. So, instead of depending on the internal sun.security.pkcs11.SunPKCS11 constructor to pass in a configuration file, you can now do the following: Provider p = Security.getProvider("SunPKCS11"); p.configure("/opt/bar/cfg/pkcs11.cfg"); We will update section 2.2 of the PKCS11 guide for JDK 9 to note this new usage. I believe that is the only section of the guide that discusses using an internal class directly. Are there any other internal PKCS11 classes you are using directly, and if so why? --Sean On 11/16/2015 10:30 AM, Vincent Ryan wrote:
Hello Glen,
JCE providers are always accessed via the Java SE public APIs and not directly via sun.* implementation classes. In JDK 9, the SunPKCS11 provider continues to be accessible via those APIs. It’s implementation classes are present in the jdk.crypto.pkcs11 module.
Thanks.
On 16 Nov 2015, at 15:21, Chris Hegarty <chris.hegarty@oracle.com> wrote:
Including the security-dev mailing list.
-Chris.
On 16/11/15 12:13, glen.vermeylen@telenet.be wrote:
In the Devoxx presentation "Prepare for JDK9", the strategy for encapsulating "sun.* " packages is discussed. The class sun.security.SunPkcs11 is not listed on slide 16 ("Uses of JDK-internal APIs"), but as the rest of sun.security.* is listed as "Non-critical, no replacement planned", will this also be case for SunPKCS11? As far as I know there is no alternative security Provider for integrating with PKCS11 aside from rolling your own jni code or using vendor-specific apis.
We rely on SunPKCS for interfacing with an HSM and belgian e-id smartcard. And even though we are aware that touching sun.* is frowned upon, first search hit on "java pkcs11" gives following page: https://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.htm... . With such elaborate documentation, you can't really blame devs to actually use this functionality :) .
Is there an alternative to SunPKCS11 or am I overlooking something?
Thanks for your response, Glen Vermeylen
Thank you all very much for your comments, No, SunPKCS11 is the only class we touch directly. For your information, we store the pkcs.cfg contents in an xml configuration, so we call the constructor SunPKCS11(Inputstream). I assume in the example below p.configure(InputStream) would also work? If I understand correctly, we cannot really anticipate the sun.x-encapsulation in jdk9? For the moment we just need to keep using SunPKCS11 and migrate to the code below when releasing for java 9? Many thanks, Glen Op 16/11/2015 om 16:46 schreef Sean Mullan:
Additionally, in JDK 9 we have added a new configure method to the java.security.Provider class that allows you to configure an underlying provider with an additional argument. The SunPKCS11 implementation has been enhanced to support this method.
So, instead of depending on the internal sun.security.pkcs11.SunPKCS11 constructor to pass in a configuration file, you can now do the following:
Provider p = Security.getProvider("SunPKCS11"); p.configure("/opt/bar/cfg/pkcs11.cfg");
We will update section 2.2 of the PKCS11 guide for JDK 9 to note this new usage. I believe that is the only section of the guide that discusses using an internal class directly.
Are there any other internal PKCS11 classes you are using directly, and if so why?
--Sean
On 11/16/2015 10:30 AM, Vincent Ryan wrote:
Hello Glen,
JCE providers are always accessed via the Java SE public APIs and not directly via sun.* implementation classes. In JDK 9, the SunPKCS11 provider continues to be accessible via those APIs. It’s implementation classes are present in the jdk.crypto.pkcs11 module.
Thanks.
On 16 Nov 2015, at 15:21, Chris Hegarty <chris.hegarty@oracle.com> wrote:
Including the security-dev mailing list.
-Chris.
On 16/11/15 12:13, glen.vermeylen@telenet.be wrote:
In the Devoxx presentation "Prepare for JDK9", the strategy for encapsulating "sun.* " packages is discussed. The class sun.security.SunPkcs11 is not listed on slide 16 ("Uses of JDK-internal APIs"), but as the rest of sun.security.* is listed as "Non-critical, no replacement planned", will this also be case for SunPKCS11? As far as I know there is no alternative security Provider for integrating with PKCS11 aside from rolling your own jni code or using vendor-specific apis.
We rely on SunPKCS for interfacing with an HSM and belgian e-id smartcard. And even though we are aware that touching sun.* is frowned upon, first search hit on "java pkcs11" gives following page: https://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.htm...
. With such elaborate documentation, you can't really blame devs to actually use this functionality :) .
Is there an alternative to SunPKCS11 or am I overlooking something?
Thanks for your response, Glen Vermeylen
-- Glen Vermeylen Schavotstraat 42 3130 Begijnendijk gsm: 0496521981
On Nov 16, 2015, at 11:46 PM, Sean Mullan <sean.mullan@oracle.com> wrote:
Provider p = Security.getProvider("SunPKCS11"); p.configure("/opt/bar/cfg/pkcs11.cfg");
p = p.configure("/opt/bar/cfg/pkcs11.cfg"); The spec for the method says: * Apply the supplied configuration argument to this provider instance * and return the configured provider. Note that if this provider cannot * be configured in-place, a new provider will be created and returned. * Therefore, callers should always use the returned provider. --Max
On 11/16/2015 08:00 PM, Wang Weijun wrote:
On Nov 16, 2015, at 11:46 PM, Sean Mullan <sean.mullan@oracle.com> wrote:
Provider p = Security.getProvider("SunPKCS11"); p.configure("/opt/bar/cfg/pkcs11.cfg");
p = p.configure("/opt/bar/cfg/pkcs11.cfg");
The spec for the method says:
* Apply the supplied configuration argument to this provider instance * and return the configured provider. Note that if this provider cannot * be configured in-place, a new provider will be created and returned. * Therefore, callers should always use the returned provider.
Yes, thanks for the correction. --Sean
participants (6)
-
Chris Hegarty
-
Glen Vermeylen
-
glen.vermeylen＠telenet.be
-
Sean Mullan
-
Vincent Ryan
-
Wang Weijun