Add PKCS#11 3.2 bindings + plug them into the cryptoki

[Jakuje]

The PKCS#11 3.2 headers are available and considered final:

https://github.com/latchset/pkcs11-headers/tree/main/public-domain/3.2

This pulls the new headers, regenerates bindings and adjusts the initialization so they can be used.

I took also the chance to update bindgen to 0.71.1 once we generate new binding version

[Jakuje]

Oh, lovely! The CI does not like the generated binding as it is too complex.

error: very complex type used. Consider factoring parts into `type` definitions
    --> /home/runner/work/rust-cryptoki/rust-cryptoki/cryptoki-sys/src/bindings/x86_64-unknown-linux-gnu.rs:6801:35
     |
6801 |       pub C_UnwrapKeyAuthenticated: Result<
     |  ___________________________________^
6802 | |         unsafe extern "C" fn(
6803 | |             arg1: CK_SESSION_HANDLE,
6804 | |             arg2: *mut CK_MECHANISM,
...    |
6814 | |         ::libloading::Error,
6815 | |     >,
     | |_____^
     |

Who would say it for a function with 10 arguments:

    pub C_UnwrapKeyAuthenticated: Result<
        unsafe extern "C" fn(
            arg1: CK_SESSION_HANDLE,
            arg2: *mut CK_MECHANISM,
            arg3: CK_OBJECT_HANDLE,
            arg4: *mut CK_BYTE,
            arg5: CK_ULONG,
            arg6: *mut CK_ATTRIBUTE,
            arg7: CK_ULONG,
            arg8: *mut CK_BYTE,
            arg9: CK_ULONG,
            arg10: *mut CK_OBJECT_HANDLE,
        ) -> CK_RV,
        ::libloading::Error,
    >,  

Is this something we should fix in the generated bindings or open an issue for the bindgen? Not sure if this is a new issue with the new bindgen, but more likely the issue of the new PKCS#11 API having that insane number of arguments ....

[wiktor-k]

Hmm fortunately this is just a clippy issue. I guess suppressing it somewhere would be an okayish workaround. (maybe in lib.rs of -sys?)

I'd still report it to bindgen. This may improve their code generation or at least make them consider adding the lint suppression in the generated code.

[Jakuje]

Thanks for the pointer! I see the lib.rs has already some more warnings ignored. I am not sure if there is some way how to improve the code generation to avoid this. I can think of using some temporary named type for the function, but I think it just moves the problem one more function argument away.

I think this is inherent issue of the PKCS#11 specification, introducing this complex functions.

[wiktor-k]

I am not sure if there is some way how to improve the code generation to avoid this.

FWIW I didn't mean that. Slapping the lint suppression there is sufficient enough for me.

[Jakuje]

Kryoptic tests now fail as there are few bugs in the last release that were already fixed in main. I think this is already good for first reviews, but I would probably wait for the pkcs11 3.2 to get released officially and I will likely implement also the SLH-DSA (they look quite simple and similar to the ML-DSA, but I do not have an implementation to test against yet).

[hug-dev]

Feel free to ping us when you want us to review this again!

[Jakuje]

I think this should be ready for reviews! Rebased and updated links to the final headers.

[teythoon]

I found a small issue. When I ask for an AttributeType::MlDsaParameterSet, the token returns an Attribute::ParameterSet.

I think the patch introduces AttributeType::MlDsaParameterSet as an alias for AttributeType::ParameterSet. Both MlDsaParameterSet and ParameterSet map to CKA_PARAMETER_SET, and therefore the distinction is lost, and the response will be a ParameterSet.

[Jakuje]

I found a small issue. When I ask for an AttributeType::MlDsaParameterSet, the token returns an Attribute::ParameterSet.

I think the patch introduces AttributeType::MlDsaParameterSet as an alias for AttributeType::ParameterSet. Both MlDsaParameterSet and ParameterSet map to CKA_PARAMETER_SET, and therefore the distinction is lost, and the response will be a ParameterSet.

Yeah, I was aware of this issue, but I am not sure how this could be easily handled given that this attribute has different values for different key types. Any thoughts?

I think it would require some logic in the GetAttributeValue mapping the type to the correct aliased "subtype" based on the key type, but I really did not look into that yet.

[teythoon]

I think the aliasing is most surprising. The Rust model is a refinement of the interface model, i.e. it is more expressive. I think that is a mistake at this point. It is also surprising for people coming from the PKCS#11 spec.

Instead, I think we should offer explicit conversion functions from ParameterSetType (doesn't exist yet, and should hold a u64, and that is what Attribute::ParameterSet should use) to MlDsaParameterSet.