From glen.vermeylen at telenet.be Mon Nov 16 12:13:15 2015 From: glen.vermeylen at telenet.be (glen.vermeylen at telenet.be) Date: Mon, 16 Nov 2015 13:13:15 +0100 (CET) Subject: JEP260 -- Impact on SunPKCS11? Message-ID: <1186702340.221364065.1447675995947.JavaMail.root@telenet.be> 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.html . 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Mon Nov 16 15:21:19 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 16 Nov 2015 15:21:19 +0000 Subject: JEP260 -- Impact on SunPKCS11? In-Reply-To: <1186702340.221364065.1447675995947.JavaMail.root@telenet.be> References: <1186702340.221364065.1447675995947.JavaMail.root@telenet.be> Message-ID: <5649F46F.6070902@oracle.com> Including the security-dev mailing list. -Chris. On 16/11/15 12:13, glen.vermeylen at 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.html > . 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 From vincent.x.ryan at oracle.com Mon Nov 16 15:30:00 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 16 Nov 2015 15:30:00 +0000 Subject: JEP260 -- Impact on SunPKCS11? In-Reply-To: <5649F46F.6070902@oracle.com> References: <1186702340.221364065.1447675995947.JavaMail.root@telenet.be> <5649F46F.6070902@oracle.com> Message-ID: <530E5C8A-F233-4C59-A212-AB107F6C69C5@oracle.com> 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 wrote: > > Including the security-dev mailing list. > > -Chris. > > On 16/11/15 12:13, glen.vermeylen at 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.html >> . 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 From sean.mullan at oracle.com Mon Nov 16 15:46:16 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 16 Nov 2015 10:46:16 -0500 Subject: JEP260 -- Impact on SunPKCS11? In-Reply-To: <530E5C8A-F233-4C59-A212-AB107F6C69C5@oracle.com> References: <1186702340.221364065.1447675995947.JavaMail.root@telenet.be> <5649F46F.6070902@oracle.com> <530E5C8A-F233-4C59-A212-AB107F6C69C5@oracle.com> Message-ID: <5649FA48.1060202@oracle.com> 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 wrote: >> >> Including the security-dev mailing list. >> >> -Chris. >> >> On 16/11/15 12:13, glen.vermeylen at 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.html >>> . 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 > From glen.vermeylen at telenet.be Mon Nov 16 19:45:21 2015 From: glen.vermeylen at telenet.be (Glen Vermeylen) Date: Mon, 16 Nov 2015 20:45:21 +0100 Subject: JEP260 -- Impact on SunPKCS11? In-Reply-To: <5649FA48.1060202@oracle.com> References: <1186702340.221364065.1447675995947.JavaMail.root@telenet.be> <5649F46F.6070902@oracle.com> <530E5C8A-F233-4C59-A212-AB107F6C69C5@oracle.com> <5649FA48.1060202@oracle.com> Message-ID: <564A3251.8080006@telenet.be> 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 >>> wrote: >>> >>> Including the security-dev mailing list. >>> >>> -Chris. >>> >>> On 16/11/15 12:13, glen.vermeylen at 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.html >>>> >>>> . 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 From weijun.wang at oracle.com Tue Nov 17 01:00:07 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 17 Nov 2015 09:00:07 +0800 Subject: JEP260 -- Impact on SunPKCS11? In-Reply-To: <5649FA48.1060202@oracle.com> References: <1186702340.221364065.1447675995947.JavaMail.root@telenet.be> <5649F46F.6070902@oracle.com> <530E5C8A-F233-4C59-A212-AB107F6C69C5@oracle.com> <5649FA48.1060202@oracle.com> Message-ID: <6AD76F3D-A16A-464C-9A03-35A1046C3301@oracle.com> > On Nov 16, 2015, at 11:46 PM, Sean Mullan 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 From sean.mullan at oracle.com Tue Nov 17 14:15:22 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 17 Nov 2015 09:15:22 -0500 Subject: JEP260 -- Impact on SunPKCS11? In-Reply-To: <6AD76F3D-A16A-464C-9A03-35A1046C3301@oracle.com> References: <1186702340.221364065.1447675995947.JavaMail.root@telenet.be> <5649F46F.6070902@oracle.com> <530E5C8A-F233-4C59-A212-AB107F6C69C5@oracle.com> <5649FA48.1060202@oracle.com> <6AD76F3D-A16A-464C-9A03-35A1046C3301@oracle.com> Message-ID: <564B367A.4010908@oracle.com> On 11/16/2015 08:00 PM, Wang Weijun wrote: > >> On Nov 16, 2015, at 11:46 PM, Sean Mullan 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