Return CKR_ATTRIBUTE_TYPE_INVALID for attributes an object lacks

[LinuxJedi]

C_GetAttributeValue failed the whole call with CKR_FUNCTION_FAILED when a template named CKA_CERTIFICATE_TYPE on a non-certificate object, so the remaining attributes were never returned. Attributes that were not supported or not applicable to the object returned CK_UNAVAILABLE_INFORMATION as the function's return value, which is not a valid CK_RV. Both cases now set ulValueLen to
CK_UNAVAILABLE_INFORMATION, continue with the template and return CKR_ATTRIBUTE_TYPE_INVALID as PKCS#11 requires.

CKA_KEY_TYPE was read from object->type for every object class, so an X.509 certificate reported CKK_RSA and a data object reported -1, and C_FindObjects on CKA_KEY_TYPE matched certificates. It is now only an attribute of key objects, and setting it on any other object returns CKR_ATTRIBUTE_TYPE_INVALID.

Reported in GitHub issue #221.

[Copilot]

Copilot review overview

🟢 Approval recommended

The implementation matches PKCS#11 requirements and includes targeted regression coverage.

Review effort: Balanced
Findings: None

What changed in this PR

Fixes PKCS#11 attribute handling reported in issue #221.

Changes:

• Returns CKR_ATTRIBUTE_TYPE_INVALID while continuing template processing.
• Restricts CKA_KEY_TYPE to key objects.
• Adds regression tests and compatibility documentation.

File	Description
src/​crypto.c	Corrects return handling and attribute setting.
src/​internal.c	Validates CKA_KEY_TYPE by object class.
tests/​pkcs11test.c	Adds comprehensive regression coverage.
tests/​pkcs11mtt.c	Updates expected return values.
README.md	Documents behavior changes.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[pdb0102]

I verified the PR on macOS arm64 (Apple clang 17) at d404186, built against wolfSSL v5.9.2-stable with
--enable-pkcs11v32 --enable-mldsa --enable-mlkem --enable-aeskeywrap --enable-aesctr --enable-aesccm
--enable-aesecb --enable-aescts --enable-aescmac.

I used a small checker (dlopen, OASIS 3.2 headers), generating a P-256 pair and a CKO_DATA object and reading
them with NULL pValue:

• private key, template {CKA_CLASS, CKA_KEY_TYPE, CKA_CERTIFICATE_TYPE}:
  v2.1.0-stable: CKR_FUNCTION_FAILED, CKA_CERTIFICATE_TYPE length 0
  this PR: CKR_ATTRIBUTE_TYPE_INVALID, lengths 8 / 8 / CK_UNAVAILABLE_INFORMATION
• data object, template {CKA_CLASS, CKA_KEY_TYPE, CKA_VALUE}:
  v2.1.0-stable: CKR_OK, CKA_KEY_TYPE length 8
  this PR: CKR_ATTRIBUTE_TYPE_INVALID, lengths 8 / CK_UNAVAILABLE_INFORMATION / 13
• asking a key only for attributes it has: CKR_OK on both.

My PKCS#11 client's full pass (generate, sign/verify, clear and wrapped import, find by
attributes, persist) runs clean against this build, and make check reports 59 tests, 55 pass,
4 skip, 0 fail.

Thanks for the quick turnaround!