On Fri, 20 Dec 2024 18:53:16 GMT, Martin Balao <mba...@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
