JEP260 -- Impact on SunPKCS11?

Glen Vermeylen glen.vermeylen at telenet.be
Tue Nov 17 05:20:15 UTC 2015


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.hegarty at oracle.com>
>>>>> 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



More information about the security-dev mailing list