1954612 - Need up update NSS for PKCS 3.1.

Status: RESOLVED FIXED

(NSS :: Libraries, enhancement, P2)

Description

[Robert Relyea]

There's a number of new features in PKCS #11 3.1, including some features where 3.1 has codified NSS vendor mechanisms and we need to switch to the new official mechanism. This bug is about moving softoken up to 3.1. I anticipate this rolling out in the following:

1. update pkcs11t.h and pkcs11n.h to match the new defines, error codes found in PKCS #11 3.1
2. update IKE support to use the new mechanism and parameters. Fortunately the new parameters have the same structures (with the same element names) as our vendor specific, so it's just a matter of name change. pkcs11n.h will keep aliases of the old names for existing applications until they can switch over.
3. a number of new attributes for supported objects have been added and need to be set able and stored in the database (if not acted on).
4. and miscellaneous semantic differences we need to update.

This work is preparation for moving everything to pkcs#11 3.2 once it's approved committe draft in about 9 days. PKCS #11 3.2 has PQ support and we can replace our vendor specific encapsulate/decapsulate code.

Comment 1

[Robert Relyea]

Attachment: Bug 1954612 Need up update NSS for PKCS 3.1.

update the headers to pkcs11 3.1

I used the tools cmp_headers.pl (in the osasis pkcs11 git repository) to find the differences. Once I applied the differences, these are the defines, typdefs, and structures that were left which I didn't update. I've included why they weren't updated in the commends below.

Here's the header diff after the update...

/cmp_headers.pl ../../published/3-01/pkcs11t.h ./pkcs11t.h
Processing header1 = ../../published/3-01/pkcs11t.h...
Processing header2 = ./pkcs11t.h...
#define CKF_MULTI_MESSGE 0x00000020UL missing from header2 ./pkcs11t.h
#define FALSE 0x00000000UL missing from header2 ./pkcs11t.h
#define TRUE 0x00000001UL missing from header2 ./pkcs11t.h

CKF_MULTI_MESSGE was a typo in the original doc, fixed in 3.2 so we won't pick up the typo.
TRUE and FALSE are enabled in the original with an optional ifdef, which we don't support (CK_TRUE and CK_FALSE are the official defines )

typedef diffs from header1 (../../published/3-01/pkcs11t.h) and header2(./pkcs11t.h)
missing typedef (typedef CK_AES_CCM_PARAMS CK_PTR CK_AES_CCM_PARAMS_PTR;) from header2 ./pkcs11t.h
missing typedef (typedef CK_AES_GCM_PARAMS CK_PTR CK_AES_GCM_PARAMS_PTR;) from header2 ./pkcs11t.h
missing typedef (typedef CK_GCM_PARAMS CK_PTR CK_GCM_PARAMS_PTR;) from header2 ./pkcs11t.h
missing typedef (typedef CK_OTP_PARAM_TYPE CK_PARAM_TYPE;) from header2 ./pkcs11t.h
missing typedef (typedef CK_ULONG CK_HSS_LEVELS;) from header2 ./pkcs11t.h
missing typedef (typedef CK_ULONG CK_LMOTS_TYPE;) from header2 ./pkcs11t.h
missing typedef (typedef CK_ULONG CK_LMS_TYPE;) from header2 ./pkcs11t.h
typedef (typedef CK_GCM_PARAMS_V3 CK_PTR CK_GCM_PARAMS_V3_PTR;) missing from header1 ../../published/3-01/pkcs11t.h

CK_AES_CCM_PARAMS and CK_AES_GCM_PARAMS are depricated in favor of CK_CCM_PARAMS and CK_GCM_PARAMS, which we (sort of) already have.
CK_GCM_PARAMS is defined in pkcs11n.h to switch between CK_GCM_PARAMS_V3 and the old CK_NSS_GCM_PARAMS with an ifdef.
CK_PARAM_TYPE is depricated in favor of CK_OTP_PARAM_TYPE
CK_HSS_LEVEL, CK_LMOTS_TYPE, CK_LMS_TYPE are from a previous HSS proposal that was changed before shipping and the update didn't happen in the header file. They are handled with attributes (which is in the header file)
CK_GCM_PARAMS_V3 is our version of CK_GCM_PARAM

missing struct 'CK_AES_CCM_PARAMS' in header2 ./pkcs11t.h
missing struct 'CK_AES_GCM_PARAMS' in header2 ./pkcs11t.h
mismatched struct entry count in struct CK_C_INITIALIZE_ARGS:
header2 7 (./pkcs11t.h)
header1 6 (../../published/3-01/pkcs11t.h)
mismatched struct entry in struct CK_C_INITIALIZE_ARGS line 5:
header2 'CK_CHAR_PTR *LibraryParameters;' (./pkcs11t.h)
header1 'CK_VOID_PTR pReserved;' (../../published/3-01/pkcs11t.h)
extra struct entry in struct CK_C_INITIALIZE_ARGS line 6:
header2 'CK_VOID_PTR pReserved;' (./pkcs11t.h)
missing struct 'CK_GCM_PARAMS' in header2 ./pkcs11t.h
missing struct 'specifiedParams' in header2 ./pkcs11t.h
struct 'CK_GCM_PARAMS_V3' missing in header1 ../../published/3-01/pkcs11t.h

CK_AES_CCM_PARAMS and CK_AES_GCM_PARAMS are depricated in favor of CK_CCM_PARAMS and CK_GCM_PARAMS, which we (sort of) already have.
CK_C_INITIALIZE_ARGS is our vendor specific version which has an optional LibraryParams. Most modules will set this to zero (pReserved) except softoken.
CK_GCM_PARAMS is defined in pkcs11n.h to switch between CK_GCM_PARAMS_V3 and the old CK_NSS_GCM_PARAMS with an ifdef.
specificParams are from a previous HSS proposal that was changed before shipping and the update didn't happen in the header file. They are handled with attributes (which is in the header file)
CK_GCM_PARAMS_V3 is our version of CK_GCM_PARAM

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

There is an r+ patch which didn't land and no activity in this bug for 2 weeks.
:rrelyea, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit BugBot documentation.

Comment 3

[Robert Relyea]

I was out for ICMC last week. I'll definitely get this checked in this week.

Comment 4

[Robert Relyea]

Attachment: Bug 1954612 Need up update NSS for PKCS 3.1: Move IPSEC to 3.1

The 3.1 definition for IPSEC is based on our vendor specific implementation. We need to move to the PKCS #11 3.1 names so applications can use the official PKCS #11 identifiers and names in their program.

1. Since the vendor structs and the pkcs #11 structs are identical except for the name, we don't need to do any struct conversion, just use the new names.
2. Since the semantics of the Mechanisms between the vendor specific and the PKSC #11 spec is identical, we only need to add the new mechanism number to our tables and switch statements.
3. For backward compatibility, we still need to use the vendor specific mechanism, so turn off the deprecation warning for those files that need those mechanism.
4. Mark all the vendor specific versions as deprecated if possible.
5. Update all out tests to use the new names and mechanism. We rework some existing code from trust to make it more general.