Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
NSS doesn't currently support KeyWrap with RSA-OAEP. In the relevant KeyWrap code, NSS attempts to force RSA PKCS#1 v1.5, even though a different mechanism was specified. This is a bug and unexpected behavior.
Version-Release number of selected component (if applicable):
Current NSS trunk. Also reported upstream here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1666891
How reproducible:
Generate a RSA
Steps to Reproduce:
1. Attempted to use PK11_PubWrapSymKey with type = CKM_RSA_PKCS_OAEP.
2. Also failed to use PK11_PubUnwrapSymKey with OAEP as this lacks a way to indicate mechanism type.
Actual results:
When attempting to use PK11_PubWrapSymKey with type = CKM_RSA_PKCS_OAEP, PK11_PubWrapSymKey succeeds but silently (!) switches to the CKM_RSA_PKCS mechanism. Partly this is because PK11_PubWrapSymKey lacks a way to specify mechanism parameters. PK11_PubUnwrapSymKey behaves similarly, but it also lacks a way to specify the exact mechanism (again, defaulting to CKM_RSA_PKCS).
Expected results:
1. Causes PK11_PubWrapSymKey to return an error when type != CKM_RSA_PKCS and a RSA key is passed in.
2. Introduces PK11_PubWrapSymKeyWithMechanism, which also accepts a mechanism parameter value to pass down into C_Wrap.
3. Introduces PK11_PubUnwrapSymKeyWithMechanism, which also accepts a type and a mechanism parameter value to pass down into C_Unwrap.
Additional info:
The motivation for this work is in conjunction with an HSM partner which has added OAEP support ahead of NIST's deprecation of PKCS#1 v1.5 in ~2023. We currently use PKCS key wrapping via JSS and would like to introduce OAEP support for people interested in using it instead. This bug blocks adoption in JSS; see also https://github.com/dogtagpki/jss/pull/624.
Hi,
Since the issue described in this bug should be resolved (VERIFIED), could you please close this bug with resolution 'CURRENTRELEASE' if this bug got fixed ?
If the fix for this is not released yet, check if this will ever get fixed. In case of a negative answer then please change it as WONTFIX.
If there's anything else to be done on this BZ, if it's still active, not released yet and we actually intend to release it, then please ignore my message.
Please note: for those bugs which are not included in errata, please add 'TestOnly' keyword, and those bugs with 'TestOnly' keyword will be closed automatically after GA.
TestOnly: Use this when there is no code delivery involved, or for use when code is already upstream and will be incorporated automatically to the next release for testing purposes only.
Thank you.
Description of problem: NSS doesn't currently support KeyWrap with RSA-OAEP. In the relevant KeyWrap code, NSS attempts to force RSA PKCS#1 v1.5, even though a different mechanism was specified. This is a bug and unexpected behavior. Version-Release number of selected component (if applicable): Current NSS trunk. Also reported upstream here: https://bugzilla.mozilla.org/show_bug.cgi?id=1666891 How reproducible: Generate a RSA Steps to Reproduce: 1. Attempted to use PK11_PubWrapSymKey with type = CKM_RSA_PKCS_OAEP. 2. Also failed to use PK11_PubUnwrapSymKey with OAEP as this lacks a way to indicate mechanism type. Actual results: When attempting to use PK11_PubWrapSymKey with type = CKM_RSA_PKCS_OAEP, PK11_PubWrapSymKey succeeds but silently (!) switches to the CKM_RSA_PKCS mechanism. Partly this is because PK11_PubWrapSymKey lacks a way to specify mechanism parameters. PK11_PubUnwrapSymKey behaves similarly, but it also lacks a way to specify the exact mechanism (again, defaulting to CKM_RSA_PKCS). Expected results: 1. Causes PK11_PubWrapSymKey to return an error when type != CKM_RSA_PKCS and a RSA key is passed in. 2. Introduces PK11_PubWrapSymKeyWithMechanism, which also accepts a mechanism parameter value to pass down into C_Wrap. 3. Introduces PK11_PubUnwrapSymKeyWithMechanism, which also accepts a type and a mechanism parameter value to pass down into C_Unwrap. Additional info: The motivation for this work is in conjunction with an HSM partner which has added OAEP support ahead of NIST's deprecation of PKCS#1 v1.5 in ~2023. We currently use PKCS key wrapping via JSS and would like to introduce OAEP support for people interested in using it instead. This bug blocks adoption in JSS; see also https://github.com/dogtagpki/jss/pull/624.