JDK-8329300 : SunPKCS11 provider checks on PKCS11 Mechanism are problematic
  • Type: CSR
  • Component: security-libs
  • Sub-Component: javax.crypto:pkcs11
  • Priority: P3
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 23
  • Submitted: 2024-03-29
  • Updated: 2024-11-04
  • Resolved: 2024-04-16
Related Reports
CSR :  
JDK-8293345 - SunPKCS11 provider checks on PKCS11 Mechanism are problematic
Relates :  
JDK-8343498 - SunPKCS11 provider checks on PKCS11 Mechanism are problematic
Description
Summary
-------

As some crypto algorithms become legacy (e.g. not strong enough for modern computers and thus being phased out), some PKCS11 library implementations may start limiting the usage for these algorithms. For example, for Cipher, only decryption is allowed but not encryption. This way, earlier encrypted data can be recovered but data won't be encrypted with legacy algorithm. Under https://bugs.openjdk.org/browse/JDK-8176837 , SunPKCS11 provider is updated to check and disable the legacy mechanisms. Further adjustment will be made to fine-tune the check and also provide a configuration attribute "allowLegacy" to disable the check if desired.

Problem
-------
Under the existing check for identifying legacy algorithms, an algorithm would be disabled if it supports decryption but not encryption, or if it supports verification but not signing. For example, an algorithm would be disabled if it supports decryption, signing, and verification but not encryption. The check should be fine-tuned to only disable the algorithm for Cipher crypto service but not Signature crypto service since both signing and verification are supported. In addition, once an algorithm is identified as legacy and disabled, there is no setting to enable them for the supported usage.

Solution
--------

Provide a "allowLegacy" configuration attribute in SunPKCS11 provider configuration file to allow applications to bypass the legacy check if needed.
In addition, existing check will be updated to disable algorithms based on the registered crypto service. Using the earlier example of the algorithm supporting decryption, signing, and verification but not encryption, it will be disabled for Cipher crypto service but remain enabled for Signature crypto service.

Specification
-------------

Update the "SunPKCS11 Configuration" paragraph under the "PKCS#11 Reference Guide" section of "Security Developer's Guide" document with the new "allowLegacy" configuration attribute. 

<table>
<tr>
<th>Attribute</th>
<th>Value</th>
<th>Description</th>
</tr>
<tr>
<td>allowLegacy</td>
<td>Boolean value, default: false</td>
<td>For Cipher crypto service registrations, PKCS11 mechanisms supporting decryption but not encryption are considered legacy and will be disabled by default. Similarly, for Signature crypto service registrations, PKCS11 mechanisms supporting verification but not signing are considered legacy and will be disabled by default. If set to <code>true</code>, SunPKCS11 provider will not disable legacy mechanisms.</td>
</tr>
</table>
Comments
I see, thanks [~darcy] very much for the pointer and explanation.
27-06-2024
Hi [~valeriep], to a first approximation, a CSR should be read-only after it is Approved and the underlying issue pushed. So at this point, I think it is reasonable to follow the process outlined in the CSR FAQ for this situation: > Q: How should I get CSR review for multiple release trains? A: Say you > want to get an interface change into JDK N and later decide the change > is also desirable and appropriate for the JDK (N-1) update release and > that update release is using the CSR process. First a CSR should be > created from the main bug targeted at JDK N. Afterward, if a backport > of the main bug covering JDK (N-1) does not already exist, a backport > of the main bug covering JDK (N-1) should be created. Then, a CSR can > be created from that backport. The CSR for the backport should > explicitly state how the interface change for the backport relates to > the interface change for the main release: either the interface change > is the same or, if it differs, what the difference is. > > If the change is being backported to multiple prior release trains and > the delta is same in each train, multiple values can be given in the > "Fix Version/s" field of the backport CSR. The values used for "Fix > Version/s" can be non-specific "pool" values, such as "17-pool" to > indicate some release in the 17 update train. If the delta of the > backport is differs in different release trains, each distinct delta > should have its own CSR. > > If it is recognized that a change should be backported when the CSR > review of the feature release is initiated, the CSR for the feature > release can also list multiple release for the update releases of > interest, subject to the conventions described above. https://wiki.openjdk.org/display/csr/CSR+FAQs HTH
27-06-2024
Thanks [~darcy] So process-wise, if this were to backported to JDK 17 or 21, how do I update the CSR to indicate the backport? Can I just add the jdk version to the "Fix Versions" after this CSR has already been approved for 23?
27-06-2024
Hi [~valeriep], from a CSR perspective, I don't see a problem with backporting this kind of change. (If the change involved updates Java SE APIs, there would be maintenance review considerations.) HTH
14-06-2024
[~darcy] Can this kind of provider configuration enhancement be backported to older JDK releases? Got external requests for backporting this if possible. Thanks in advance for the reply~
14-06-2024
Moving to Approved.
16-04-2024
Yes, thanks [~mullan] for the suggestions! Updated~
09-04-2024
I think it would it be more clear to say: > For Cipher crypto service registrations, PKCS11 mechanisms supporting > decryption but not encryption are considered legacy and will be > disabled by default. And similar wording for signature: > Similarly, for Signature crypto service registrations, PKCS11 > mechanisms supporting verification but not signing are considered > legacy and will be disabled by default.
09-04-2024
[~darcy] I renamed the attribute to "allowLegacy" and made further updates. Please let me know more clarification is needed. Thanks for the feedback~
04-04-2024
Moving to Provisional, not Approved. [~valeriep], before the CSR is Finalized, please rephrase it to more clearly describe what the situation is now vs what the situation will be afterward; I think I understand the intention, but the use of multiple-negatives in the next is a bit confusing. Thanks.
04-04-2024