Underlying library access / vendor extensions

[baloo]

First of all, thanks for this great crate / api! again!
Second, merry Christmas to those of you who celebrate!

My HSM vendor (entrust) has extensions to the standard PKCS#11 to support K/N authentication mechanisms with the HSM.
Those are documented here:
https://nshielddocs.entrust.com/api-generic/12.80/pkcs11#nshield-specific-pkcs11-api-extensions

My current idea is to implement an cryptoki::context::Pkcs11::unsafe_deref() method to that would return the underlying the libloading::Library so I could grab the missing symbols from there (This is exposed in the symbols of the ELF, no idea how it could be exposed in the C_GetFunctionList).
I'll take care of having a cbindgen wrapper for those methods.

Opening this issue to gather ideas/suggestions on that, and see if you would be open for the usecase and a PR.

It doesn't look like this is related to #105 (but I might be missing something), feel free to close as duplicate if so.

[ionut-arm]

Hey, thanks for getting in touch here as well 😄 And happy new year!

I think one other way to approach it would be to simply expose that bit of the interface gated under a Cargo feature (say, entrust-hsm), and otherwise implement the wrapper as you would for any other bit of functionality. Unless there's something that I'm missing, as I don't think I've tried anything like this before 🤔

[ionut-arm]

Hmmmmmmmm... On closer inspection following the conversation in #113 , I noticed that on the Entrust PKCS11 documentation page:

1. They link to version 2.40 of the spec.
2. They then mention EdDSA as a valid mechanism in the supported list (see here)

However, 2.40 does not mention EdDSA as a supported mechanism. At the same time, our header file - which is also, presumably, v2.40 - also contains an EdDSA constant. What.

[baloo]

Their documentation isn't exactly the best.
I mostly rely on their code samples and try and error.
I don't believe I can share the code samples as it's in a software bundle that I'm not allowed to redistribute.

Ha, well I didn't expect you to support a flavor for the vendor. I meant that I would have made a secondary library to support my use-case backed by cryptoki and that I needed cryptoki to expose the internals. I didn't expect you to support this vendor (or any).
If you're okay with this, then I'd be happy to go that way, but that places the maintenance burden on you. And if you don't have access to the hardware, ... anyway. Up to you.

[ionut-arm]

And if you don't have access to the hardware

If you create a separate library, would you run the CI straight against your HSM (or some simulator for it) to test the functionality? If so, then maybe that's a bonus point for that approach. But if not, and all testing is done manually or through some workload running somewhere separately from the "official" CI, then I don't think there's much of a difference between the two approaches.

but that places the maintenance burden on you.

It places some of the maintenance burden on us 😉 but ultimately it will come down to the users of that HSM to identify and fix the bugs in good faith, we could only check that it builds, via CI.

I can see a case being made either way, feel free to go down whichever route you think would be easier to use. And PRs are welcome, of course.

[baloo]

I don't have a simulator. All of it is tested by hand :(
And even if a simulator existed (I'd have to ask their support), this is unlikely something I can publish as it will be tied to the same export control shenanigans.

Will definitely send a PR!