contribute to the OpenJDK security group

[Tomas Gustavsson]

Awesome.

I just posted in another thread to the mailing list with some examples
where more flexibility would be needed. "PKCS#11 provider issues with
min and max size".

Another example would be to add flexibility to be more crypto "agile".
I.e. when new algorithms come out, for example SHA3. It will be included
in the PKCS#11 spec eventually, and then it takes a decent round-trip
time before it's possible to use through SunPKCS#11. So an example would
be to be able to configure new mechanisms, that does not affect any
other code in SunPKCS11, dynamically.

Yet another example, AWS CloudHSM requires you to use
CKM_RSA_X9_31_KEY_PAIR_GEN instead of CKM_RSA_PKCS_KEY_PAIR_GEN.
Patching SunPKCS11 to use it is trivial (for java programmers that is),
just replace one string with another. If it could be done dynamically
without patching java files it would be much nicer...and more stable as
it survives JDK upgrades.

Cheers,
Tomas

On 2018-02-01 20:25, Martin Balao wrote:
> Hi Tomas,
> 
> As Andrew said, I've been working on some SunPKCS11 improvements related
> to native memory leaking. You can find details of this work here [1].
> Feedback is always welcomed.
> 
> What do you mean with "more flexibility"?
> 
> --
> [1]
> - http://mail.openjdk.java.net/pipermail/security-dev/2017-October/016400.html
> 
> On Wed, Jan 24, 2018 at 8:06 AM, Andrew Haley <aph at redhat.com
> <mailto:aph at redhat.com>> wrote:
> 
>     On 24/01/18 10:39, Tomas Gustavsson wrote:
>     > Imho the P11 layer always needs attention. To work properly we're
>     > relying on some patches, where parts was recently merged into OpenJDK.
>     > We just started testing the Amazon CloudHSM, and that requires changes
>     > to SunPKCS11 as well to work. Not always bad in SunPKCS11 as some P11
>     > libraries out there do strange non-conforming stuff, but there's room
>     > for more flexibility nevertheless.
> 
>     Martin Balao has been heavily reworking this layer because it leaks
>     native memory.  I'll let him fill you in on the details.
> 
>     --
>     Andrew Haley
>     Java Platform Lead Engineer
>     Red Hat UK Ltd. <https://www.redhat.com>
>     EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> 
>