<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
I’ve added the SecurityKeyFactort.Generic part into <a href="https://bugs.openjdk.org/browse/JDK-8346997">https://bugs.openjdk.org/browse/JDK-8346997</a>. You can remove yours.
<div><br>
</div>
<div>Thanks,</div>
<div>Weijun<br id="lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On Jan 9, 2025, at 10:06, Martin Balao <mbalao@redhat.com> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div dir="ltr">
<div>If it's more clear or easier for you, we can do it.</div>
<div><br>
</div>
<div>I've re-opened JDK-8346720. We will reference JDK-8346720 in PR #22215's commit for the code changes part. My understanding is that PR #22215 will now be blocked by JDK-8346720's CSR.</div>
<div><br>
</div>
<div>We look forward to having the CSR for JDK-8346720 reviewed, so we can move it to Proposed.</div>
<div><br>
</div>
<div>Regards,</div>
<div>Martin.-</div>
<div><br>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Wed, Jan 8, 2025 at 9:35 PM Wei-Jun Wang <<a href="mailto:weijun.wang@oracle.com">weijun.wang@oracle.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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).<br>
<br>
This is my suggestion:<br>
<br>
1. Re-open JDK-8346720, but you can cover the code change in PR #22215.<br>
2. We will create a sub-task for it to update the SunPKCS11 Provider doc.<br>
3. The Standard Name change can be combined into JDK-8346997 or stay inside JDK-8346720.<br>
<br>
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.<br>
<br>
Thanks,<br>
Weijun<br>
<br>
<br>
> On Jan 8, 2025, at 18:35, Martin Balao <<a href="mailto:mbalao@redhat.com" target="_blank">mbalao@redhat.com</a>> wrote:<br>
> <br>
> Hi Weijun,<br>
> <br>
> Happy new year to you as well!<br>
> <br>
> 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?<br>
> <br>
> Regards,<br>
> Martin.-<br>
> <br>
> <br>
> On Tue, Jan 7, 2025 at 11:44 AM Wei-Jun Wang <<a href="mailto:weijun.wang@oracle.com" target="_blank">weijun.wang@oracle.com</a>> wrote:<br>
> Hi Martin,<br>
> <br>
> Happy New Year!<br>
> <br>
> I’m currently working on<br>
> <br>
> 8346997: Java Security Standard Algorithm Names spec should include key algorithm names<br>
> <a href="https://bugs.openjdk.org/browse/JDK-8346997" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8346997</a>
<br>
> <br>
> As you can see, it involves only spec changes.<br>
> <br>
> Some days ago, we asked you to close out 8346720: Support Generic keys in SunPKCS11 SecretKeyFactory (<a href="https://bugs.openjdk.org/browse/JDK-8346720" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8346720</a>) 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.<br>
> <br>
> 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.<br>
> <br>
> What do you think?<br>
> <br>
> Thanks,<br>
> Weijun<br>
> <br>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>