Underlying library access / vendor extensions about rust-cryptoki HOT 5 OPEN

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 🤔

from rust-cryptoki.

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.

from rust-cryptoki.

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.

from rust-cryptoki.

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.

from rust-cryptoki.

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!

from rust-cryptoki.