The xml just contains the literal contents of the .cfg file, we then
pass this string through a ByteArrayInputstream to the constructor, like
following sample code:
final String pkcs11Config =
"name=eIDCard\nlibrary=C:/Windows/System32/beidpkcs11.dll"
+ "\nslotListIndex=0"
+ "\nshowInfo=true";
final SunPKCS11 eidPkcs = new SunPKCS11(new
ByteArrayInputStream(pkcs11Config.getBytes()));
regards,
Op 16/11/2015 om 22:52 schreef Sean Mullan:
On 11/16/2015 02:45 PM, Glen Vermeylen wrote:
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?
No, currently it only takes a String, which is the filename in this case.
How did your xml configuration work? The SunPKCS11 provider only
understands the format as specified in
http://docs.oracle.com/javase/8/docs/technotes/guides/security/p11guide.html#Config
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?
Correct.
--Sean
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.hega...@oracle.com>
wrote:
Including the security-dev mailing list.
-Chris.
On 16/11/15 12:13, glen.vermey...@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
