RFC: Upstreaming CKM_HKDF_DERIVE — design questions

[Hussainity]

Hi, I have a working CKM_HKDF_DERIVE implementation against current main and would like to upstream it. Before opening a PR, I'd appreciate input on a few design choices.

What I have

• CKM_HKDF_DERIVE per PKCS#11 v3, parsing CK_HKDF_PARAMS.
• All three salt sources (NULL / DATA / KEY) and all four extract/expand combinations.
• Sensitive/extractable propagation matching CKM_CONCATENATE_BASE_AND_KEY.
• Support for all PRFs.
• Some RFC 5869 Test Cases passing as a CppUnit test.

Known gaps:

• OpenSSL backend only.
• HKDF logic inline in SoftHSM.cpp, not under src/lib/crypto/.
• CKK_HKDF not wired into newP11Object / P11Attributes.
• No CKM_HKDF_KEY_GEN / CKM_HKDF_DATA, no FIPS gating.

Questions

1. Crypto layer — should I model HKDF after MacAlgorithm (new + OSSL/Botan subclasses via CryptoFactory), or build it on top of existing MacAlgorithm HMAC and skip a new factory entry?
2. Botan backend — required for merge, or acceptable as follow-up?
3. FIPS — for WITH_FIPS builds, allow SHA-2 PRFs only and compile out the rest, matching the CKM_DES_* pattern?
4. CKK_HKDF object representation — reuse P11GenericSecretKeyObj (like the CKK_*_HMAC types), or introduce P11HKDFSecretKeyObj?
5. Would CKM_HKDF_KEY_GEN / CKM_HKDF_DATA be required to merge?
6. Tests — anything beyond DeriveTests.cpp and RFC 5869 vectors you'd like to see?

Motivation
My project uses SoftHSM in CI and needs HKDF; we'd rather upstream than maintain a fork.

Thanks!

[bukka]

Hi, thanks for raising this.

1. Wrap native library HKDF via a new HKDF abstract plus OSSLHKDF subclass through CryptoFactory, not on top of MacAlgorithm.
2. OpenSSL only is fine. Botan can be done later like we did for ML-DSA and others.
3. Yes, gate PRFs under WITH_FIPS matching CKM_DES_*
4. Reuse P11GenericSecretKeyObj like CKK_*_HMAC
5. Think CKM_HKDF_KEY_GEN but CKM_HKDF_DATA can be deferred.
6. Try to cover as much as code you can.