rust-pkcs11
rust-pkcs11 copied to clipboard
mheese
Support for partial implementations
Hi!
Currently the library seems to offer support only for PKCS11 implementations that support all functions described in the spec. However, the official documentation indicates that, to be compliant with PKCS11, only a subset of the functionality within the main spec must be implemented - the rest is optional. I can see from the README (and from using SoftHSM ourselves!) that there are implementations that do this, but others do not and interacting with these would be impossible because of how the Ctx constructor works.
Our suggestion was that instead of erroring out of the constructor if any of the methods is unavailable, an Option or Result can be kept and the error returned when the corresponding Ctx method is called. Does that sound sensible from your perspective?
Oh yeah! You are absolutely right... and I thought by now I know that standard by heart, and I could recite it in my sleep! 😄 ... I'm not sure how I missed such a fundamental part - in particular because I just read about it not too long ago in the v3.00 specifications (I somehow assumed it was new there).
We have a similar situation already here: https://github.com/mheese/rust-pkcs11/blob/master/src/lib.rs#L162 ... which is handled with what I believe you have in mind here https://github.com/mheese/rust-pkcs11/blob/master/src/lib.rs#L393, and then errors in the function call like this https://github.com/mheese/rust-pkcs11/blob/master/src/lib.rs#L1848
@ionut-arm is that what you have in mind? if yes, do you want to make a PR for this? I agree that making them optional is the right choice then. Additionally it would actually be great if one could find out the profile of a token as well.
Actually...! We just realised that we had tested with your crate on a PKCS11 implementation that only supports part of the functions and it worked - this was some time before we noticed the Ctx constructor method. Looking in the spec, it actually says this for CK_FUNCTION_LIST:
Every function in the Cryptoki API MUST have an entry point defined in the Cryptoki library’s CK_FUNCTION_LIST structure. If a particular function in the Cryptoki API is not supported by a library, then the function pointer for that function in the library’s CK_FUNCTION_LIST structure should point to a function stub which simply returns CKR_FUNCTION_NOT_SUPPORTED.
The wording is a bit uncertain and could be interpreted both ways (for how the missing functions should be handled), but we can stick with the one more favourable to us.
So I guess this issue becomes a non-issue, you did know this by heart 😅 Apologies for the confusion. I think the functions that are added in subsequent revisions should definitely be placed in an Option, but I think you already cover all PKCS11 v2.x functions. v3 is a different matter
@ionut-arm feels kind of weird telling you to switch to the cryptoki crate 😄 ... as you obviously know by now I'm not maintaining this any longer. Life happened.... thanks for picking that up! And btw, if you guys want to take over ownership of the pkcs11 crate on crates.io, please let me know.