Question on crypto backends

[ionut-arm]

Hi,

I wanted to check which crypto backends you're planning to integrate for this project, and whether Parsec could play a role here as an option/alternative. @puiterwijk already has some insight into the project, but a TLDR is that we're building it to be an abstraction over hardware crypto engines/modules in the form of a userspace service, with support for a number of (mainly asymmetric) crypto primitives. The caveat would be that, if the library is aimed at early stages of the boot cycle then Parsec would not be a good fit :)

Let me know what you think, if there is any overlap here that we could work towards.

[petreeftime]

Hi @ionut-arm!

I've had a brief look over Parsec and it seems like it could be a good way to integrate a few other crypto providers. So far I don't know any users that use this during boot, but I would like to be able to keep a somewhat minimal set of requirements by default (eg. just libcrypto or ring), we are using this is a rather constrained environment and keeping things simple is critical.

At the moment, the only requirement that I know of, from our customers, is integration with AWS KMS (#23), but other than that, I don't know of additional plans from us to extend the library in the near future.

However, I don't see an issue adding Parsec as an optional dependency, in case someone wants to use this with a HSM or another PKCS11 provider (including perhaps https://github.com/aws/aws-nitro-enclaves-acm), and perhaps removing the TPM support as it is right now and using it through Parsec.

[ionut-arm]

Hi @petreeftime !

Thanks for taking the time to have a look! That sounds reasonable, I'll close this and open another issue to track implementing a backend based on Parsec.

For ACM for Nitro Enclaves do you reckon we should include some end-to-end testing on our side, as part of the backend implementation here?