pkcs11.h does not declare CK_EC_KDF_TYPE

[Aearsis]

The section of compatible defines in pkcs11.h is missing

#define ck_ec_kdf_t CK_EC_KDF_TYPE

It is well possible that more definitions are missing, it might be worth checking them all. Shall I invest more time into that, e.g. prepare a PR?

[ueno]

Sure, such changes are always welcome.

[Aearsis]

OK, I did some research and found the following inconsistencies:

• CK_EC_KDF_TYPE alias is missing, the type is defined as ck_ec_kdf_t (the original issue)
• CK_OTP_PARAM_TYPE is still the former CK_PARAM_TYPE (changed in errata 01 of PKCS#11 2.40)
• CK_JAVA_MIDP_SECURITY_DOMAIN typedef to ulong is missing completely
• CK_CERTIFICATE_CATEGORY_* and CK_SECURITY_DOMAIN_* constant definitions are missing
• a lot of CK_*_PARAMS structures and their _PTR typedefs are missing completely

Which of these issues we want to resolve? It seems to me that at least those _PARAMS structures are missing intentionaly.

[ueno]

We usually add constants on a request basis (from the consumers such as SoftHSM), so if you have any use-case with the missing constants it's always a good idea to add them right away.

Ideally we should be able to use the verbatim copy of the OASIS provided header files, but it's currently not possible because of legal concerns:
https://phabricator.services.mozilla.com/D63241#2040953

[Aearsis]

Actually, softhsm/SoftHSMv2#599 is where I noticed the CK_EC_KDF_TYPE, and it would be nice to have there. The others are without use case, just good to bring along.

I will add the constants and types, as the attributes can be stored by SoftHSM, but left the missing mechanism param structures, as there's no use for them now.

What about P11_KIT_CRYPTOKI_VERSION_REVISION? It is supposed to be changed every time, but history shows the opposite :) Shall I bump it with the change?

[ueno]

What about P11_KIT_CRYPTOKI_VERSION_REVISION? It is supposed to be changed every time, but history shows the opposite :) Shall I bump it with the change?

Yeah, that would make sense (we probably should add a check for this in commit hook, etc).