RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v8]
Martin Balao
mbalao at openjdk.org
Tue Jan 7 20:21:42 UTC 2025
On Fri, 20 Dec 2024 18:53:16 GMT, Martin Balao <mbalao at openjdk.org> wrote:
>>> I'll split this PR and clarify the intention for _Generic_ keys in the new CSR. @seanjmullan, based on what we discussed with Weijun, would you be open to making this PR dependent on the _Generic_ one? Otherwise, I'll have to trim the test and we will loose coverage.
>>
>> First, I don't think it is necessary to make this PR dependent on [the Generic one](https://bugs.openjdk.org/browse/JDK-8346720). Go ahead and integrate this issue after you get the necessary reviews. I think it is ok if it is using "Generic" as long as we have a plan to address that in a follow-up issue and add it as a standard name, or revert to something else if we decide differently.
>>
>> Second, I would like to expand the scope of the new issue to include other uses of "Generic", as it is also used by the KEM API when [decapsulating](https://github.com/openjdk/jdk/blob/59c2aff1edffb66762bbbe5e310913f87953be5b/src/java.base/share/classes/javax/crypto/KEM.java#L206). Weijun just opened [an issue](https://bugs.openjdk.org/browse/JDK-8346736) that will address that and I think we should address the PKCS11 "Generic" name at the same time - I also want to make sure we think this through a bit more. So I would dup JDK-8346720 to the issue Weijun created.
>>
>> In a worse case scenario, if we decide we don't want to standardize the PKCS11 "Generic" name, then maybe you could change it to something more P11 specific later, like "P11Generic".
>
>> > I'll split this PR and clarify the intention for _Generic_ keys in the new CSR. @seanjmullan, based on what we discussed with Weijun, would you be open to making this PR dependent on the _Generic_ one? Otherwise, I'll have to trim the test and we will loose coverage.
>>
>> First, I don't think it is necessary to make this PR dependent on [the Generic one](https://bugs.openjdk.org/browse/JDK-8346720). Go ahead and integrate this issue after you get the necessary reviews. I think it is ok if it is using "Generic" as long as we have a plan to address that in a follow-up issue and add it as a standard name, or revert to something else if we decide differently.
>>
>
> Thanks, we appreciate this flexibility. My understanding is that we are now waiting for @driverkt's review, unless someone wants to make any other comment in this PR.
>
>> Second, I would like to expand the scope of the new issue to include other uses of "Generic", as it is also used by the KEM API when [decapsulating](https://github.com/openjdk/jdk/blob/59c2aff1edffb66762bbbe5e310913f87953be5b/src/java.base/share/classes/javax/crypto/KEM.java#L206). Weijun just opened [an issue](https://bugs.openjdk.org/browse/JDK-8346736) that will address that and I think we should address the PKCS11 "Generic" name at the same time - I also want to make sure we think this through a bit more. So I would dup JDK-8346720 to the issue Weijun created.
>>
>> In a worse case scenario, if we decide we don't want to standardize the PKCS11 "Generic" name, then maybe you could change it to something more P11 specific later, like "P11Generic".
>
> Makes sense. Let us know if you need our collaboration. For now, I closed [JDK-8346720](https://bugs.openjdk.org/browse/JDK-8346720) as a duplicate of [JDK-8346736](https://bugs.openjdk.org/browse/JDK-8346736).
> @martinuy I think the CSR can be Proposed while code reviews are still ongoing.
Moved to `Proposed`. Thanks.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/22215#issuecomment-2576149599
More information about the security-dev
mailing list