Closed rjzak closed 1 year ago
Can you clarify what you mean with "custom" keys? Are these keys that are not used with algorithms specified by wasi-crypto?
An implementation can implement custom algorithms in addition to the specified ones.
The external secrets API also let applications store arbitrary, raw keys, that can later be retrieved using identifiers. The host is responsible for securely storing them. Seems like this is what you are looking for?
If the keys predefined by the runtime will be used with wasi-crypto algorithms, the way to do it is to use managed keys.
Handles can be retrieved from identifiers (ex: keypair_from_id()
).
It seems that managed keys is what I need. I'll investigate that further. Thank you.
How would you load custom public & private keys into the host-side Wasi-Crypto context? I see I can do something like this:
But
keypair_import()
returns aHandle
object. How would the guest code be able to use the loaded keys without having to know ahead of time that there are pre-loaded keys, or some value to get aHandle
object? Could we have a secondary constructor which receives the keys?It also seems like a new guest API might be needed to instead use the existing keys, instead of
SignatureKeyPair::generate("Algo_Name");
. I'd like to suggest something like:SignatureKeyPair::get_keypair();
orSignatureKeyPair::get_keypair_or_default("Algo_name");
. Or am I missing something like this is already possible?With Enarx, we have our own cert that proves that a workload is running in a trusted execution environment. We'd like the workload to be able to use the cert without having to be aware of this, so peer applications can validate the application is also in a trusted execution environment.