JEP260 -- Impact on SunPKCS11?

[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
>>>
>