-
Notifications
You must be signed in to change notification settings - Fork 94
Description
I'm interested in developing an EST-based certificate enrollment infrastructure with TLS-based client authentication with private keys stored in a Hardware Security Module (HSM), Trusted Platform Module (TPM) or similar. This means that the private key for the client authentication certificate will not be directly accessible in the form of a file or memory buffer. Key operations instead need to be performed through "crypto provider" interfaces like Cryptography Next Generation (CNG) on Windows or similar APIs on other platforms. Certificates are then instead referred to by name, like e.g. CurrentUser\My\MyClientAuthCertificate or thumbprint in APIs relying on them for crypto operations.
After having taken a quick look at the libest sources, then it seems like the API is currently bound to private keys being loaded into EVP_PKEY memory buffers using either the read_private_key or load_private_key functions and then passed as arguments to est_client_set_auth(EST_CTX *ctx, const char *uid, const char *pwd, X509 *client_cert, EVP_PKEY *private_key).
I'm wondering if usage of memory buffers for client certificate private keys is a fundamental limitation for this project, or if there are plans for also supporting HSM/TPM-stored keys in the future?
I don't know if it's relevant, but there seem to be some libcurl dependencies in the sources. I stumbled across a related Support secure enclaves by referencing key-pairs by name instead of passing actual key(s) request in libcurl that as of today does not seem to have been implemented.