JEP260 -- Impact on SunPKCS11?

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