From Fedora Project Wiki
Line 62: Line 62:
option 1
option 1


#define NSS_PKCS11_2_0_COMPAT 1
#define NSS_PKCS11_2_0_COMPAT 1


or compile with -DNSS_PKCS11_2_0_COMPAT
or compile with -DNSS_PKCS11_2_0_COMPAT

Revision as of 16:24, 20 May 2020

Change Proposal Name

NSS CK_GCM_PARAMS change.

Summary

Because of changes to the PKCS #11 spec in PKCS #11 v3.0, NSS needs to change the definition of CK_GCM_PARAMS in a source incompatible way. Upstream made this change in NSS 3.52.

Owner

  • Name: Bob Relyea
  • Owners of other packages are unknown.
  • Email: rrelyea@redhat.com

Current status

  • Targeted release: Fedora 34
  • Last updated: 2020-05-20
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

PKCS #11 2.40 had a mismatch between the SPEC and the released header file for CK_GCM_PARAMS. The latter is controlling. We created or header based on the former. In PKCS #11 v3.0 the reconciled this, but it left us with. The new (to NSS) definition has a new field ulIvBits, which must be set correctly.

To solve this, the NSS 3.52 headers has both definitions: CK_NSS_GCM_PARAMS is the original NSS definition and CK_GCM_PARAMS_V3 is the new (to NSS) definition. CK_GCM_PARAMS takes on one or the other based on the definition of NSS_PKCS11_2_0_COMPAT.

The current NSS builds in fedora have changes the sense of this #define to NSS_PKCS11_3_0_STRICT to get the new behavior, and keep the old behavior by default. NSS builds will automatically switch back to the upstream default in Fedora 34. None of the changes below actually requires setting the NSS_PKCS11_3_STRICT define, though doing so can test that all but option 1 is functioning.

Applications can fix this the following ways:

option 1

#define NSS_PKCS11_2_0_COMPAT 1

or compile with -DNSS_PKCS11_2_0_COMPAT

your app will compile and run using current and older versions of NSS, but may break on newer tokens that use the new definition (same as the previous behavior.


option 2

rename CK_GCM_PARAMS to CK_NSS_GCM_PARAMS (this will now require nss >= 3.52 to compile, but won't change based on NSS_PKCS11_2_0_COMPAT). Like option 2 it may break on newer tokens.


option 3

rename CK_GCM_PARAMS to CK_GCM_PARAMS_V3 and set ulIvBits to ulIvLen*8.

This will require nss >= 3.52 to compile and to run. Should run on all run tokens.


option 4

Move to PK11_AEADOp interface, which all requires nss >= 3.52 to compile and run, but it's less surprising and the dependency will be picked up automatically because you are using a new for 3.52 interface.


Option 4 is the preferred solution. It takes advantage the the PKCS #11 v3 interface for AES_GCM while removing any PCKS #11 param structure dependency in the application. It also handles backward compatibility on older tokens and automatically detects which flavor of data structure is supported. It also would help with applications that support two or more of AES_GCM, AES_CCM, and CHACHA_POLY.

Benefit to Fedora

This change will keep fedora with the NSS upstream as well as make Fedora compliant with the official OASIS PKCS #11 spec.

Scope

  • Proposal owners:

NSS 3.52 has already had builds made with the reverse sense. NSS will need to be rebuilt at the start of Fedora 34.


  • Other developers:

Developers need to choose one of these options by fedora 34 or their rebuilt packages will fail at runtime.

option 1

  1. define NSS_PKCS11_2_0_COMPAT 1

or compile with -DNSS_PKCS11_2_0_COMPAT

your app will compile and run using current and older versions of NSS, but may break on newer tokens that use the new definition (same as the previous behavior.


option 2

rename CK_GCM_PARAMS to CK_NSS_GCM_PARAMS (this will now require nss >= 3.52 to compile, but won't change based on NSS_PKCS11_2_0_COMPAT). Like option 2 it may break on newer tokens.


option 3

rename CK_GCM_PARAMS to CK_GCM_PARAMS_V3 and set ulIvBits to ulIvLen*8.

This will require nss >= 3.52 to compile and to run. Should run on all run tokens.


option 4

Move to PK11_AEADOp interface, which all requires nss >= 3.52 to compile and run, but it's less surprising and the dependency will be picked up automatically because you are using a new for 3.52 interface.


Option 4 is the preferred solution. It takes advantage the the PKCS #11 v3 interface for AES_GCM while removing any PCKS #11 param structure dependency in the application. It also handles backward compatibility on older tokens and automatically detects which flavor of data structure is supported. It also would help with applications that support two or more of AES_GCM, AES_CCM, and CHACHA_POLY.


I believe there is no additional release engineering requirements for this bug. Only packages which use CK_AES_GCM_PARAMS need action and the action can happen outside the release process.

  • Policies and guidelines:

Thid doesn't

  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

How To Test

1. Grep for CK_AES_GCM_PARAMS in our source tree. If it does not appear, no further action is needed. 2. If you choose options 2-4, you can do a normal test build and run your normal tests against any version of nss > 3.52 3. If you think you don't need to make a change, compile your package with -DNSS_PKCS11_3_0_STRICT and run your normal tests. If everything works should should not need further action. 4. option 1 would require building NSS without the patch and then rebuilding with your package. Only use option 1 if you need to build your package against older versions of nss. NOTE: The effect of not changing will create a runtime issue where your AES_GCM call will fail after recompiling.


User Experience

Users who don't build their own packages will see no issues. Users that build their own packages and use classic NSS AES_GCM will see runtime failures after a rebuild unless they update their packages.

Dependencies

nss-3.52 or greater.


Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No
  • Blocks product? product

If it all falls on the floor, we can delay the update to NSS_PKCS11_3_0_STRICT by default. None of the mitigation strategies care about what the default value is

Documentation

Description contains the notes that upstream is working on, modified for fedora. I'll include links once upstream has released them.

Release Notes

Replicate the description in the release notes of fedora 33 and fedora 34. Users can make their own changes in fedora 33 before fedora 34 is released.