On 8346720: Support Generic keys in SunPKCS11 SecretKeyFactory

[Wei-Jun Wang]

But JDK-8346720 does not sound like only spec change. It needs real code and a change to SunPKCS11 Provider doc (which is not a spec).

This is my suggestion:

1. Re-open JDK-8346720, but you can cover the code change in PR #22215.
2. We will create a sub-task for it to update the SunPKCS11 Provider doc.
3. The Standard Name change can be combined into JDK-8346997 or stay inside JDK-8346720.

The CSR for JDK-8346720 is still needed because it has at least the SunPKCS11 Provider change part. This is also the reason why JDK-8346720 needs to be re-opened.

Thanks,
Weijun


> On Jan 8, 2025, at 18:35, Martin Balao <mbalao at redhat.com> wrote:
> 
> Hi Weijun,
> 
> Happy new year to you as well!
> 
> Thanks for the heads up. My understanding is that the spec changes will be done in JDK-8346997 and the code changes will be integrated as part of "8328119: Support HKDF in SunPKCS11 (Preview) (PR #22215)", so we don't have to create dependent PRs. Has there been any plan change since we reached this agreement?
> 
> Regards,
> Martin.-
> 
> 
> On Tue, Jan 7, 2025 at 11:44 AM Wei-Jun Wang <weijun.wang at oracle.com> wrote:
> Hi Martin,
> 
> Happy New Year!
> 
> I’m currently working on
> 
>     8346997: Java Security Standard Algorithm Names spec should include key algorithm names
>     https://bugs.openjdk.org/browse/JDK-8346997 
> 
> As you can see, it involves only spec changes.
> 
> Some days ago, we asked you to close out 8346720: Support Generic keys in SunPKCS11 SecretKeyFactory (https://bugs.openjdk.org/browse/JDK-8346720) because it’s closely related to the enhancement I’m working on. However, I believe your enhancement may require real code changes, which might be better handled separately.
> 
> It might make sense to re-open JDK-8346720. I could still include the Standard Names changes for SecretKeyFactory.Generic in my enhancement, leaving just the SunPKCS11 Provider changes for you.
> 
> What do you think?
> 
> Thanks,
> Weijun
>