If I understand correctly, the intention is to avoid having to use ENGINE_load_private_key() directly or having to say '-keyform ENGINE' to the openssl commands, and to avoid having to remember some cryptic key identity to give with '-key'. Instead of all that, just give the name of a .pem file with '-key' and if that file contains some kind of magic information that the engine can understand, it will dig out a reference to the hw protected key.
Many years ago, I was thinking of something along the same lines, but with a .pem file that would just have a few headers, holding the name of the intended engine and the key identity, something like this: -----BEGIN PRIVATE KEY----- X-key-id: flarflarflar X-key-engine: foo -----END PRIVATE KEY----- The intent was that the PEM code would be massaged to recognise these headers and would then use ENGINE_by_id() / ENGINE_load_private_key() with those data and that would be it. James, did I catch your intention about right? I think that's essentially what e_tpm.c does for loading keys, right? Cheers, Richard ( gotta love to see someone use "flarflarflar" as a key id ;-) ) In message <60f14e07-d0dc-486f-aff7-c74f5929b...@ll.mit.edu> on Wed, 16 Nov 2016 15:56:05 +0000, "Blumenthal, Uri - 0553 - MITLL" <u...@ll.mit.edu> said: uri> My apologies – I don’t fully understand “file based engine keys”. I thought the keys were either on a hardware device (a TPM, a PKCS#11-accessible HSM or smartcard, etc), or in a file. If a key is in a file – it’s not an “engine key”. uri> uri> What am I missing, and what’s your use case(s)? uri> — uri> Regards, uri> Uri uri> uri> uri> On 11/16/16, 10:46 AM, "openssl-dev on behalf of James Bottomley" <openssl-dev-boun...@openssl.org on behalf of james.bottom...@hansenpartnership.com> wrote: uri> uri> [David Woodhouse told me that openssl-dev is a closed list, so the uri> original messages got trashed. This is a resend with apologies to uri> David and Peter] uri> uri> One of the principle problems of using TPM based keys is that there's uri> no easy way of integrating them with standard file based keys. This uri> proposal adds a generic method for handling file based engine keys that uri> can be loaded as PEM files. Integration into the PEM loader requires a uri> BIO based engine API callback which the first patch adds. The second uri> patch checks to see if the key can be loaded by any of the present uri> engines. Note that this requires that any engine which is to be used uri> must be present and initialised via openssl.cnf. uri> uri> I'll also post to this list the patch to openssl_tpm_engine that makes uri> use if this infrastructure so the integration of the whole can be seen. uri> It should also be noted that gnutls has had this functionality since uri> 2012. uri> uri> The patch was done against 1.0.2h for easier testing and you can try it uri> and the openssl_tpm_engine out (if you run openSUSE) here: uri> uri> https://build.opensuse.org/project/show/home:jejb1:Tumbleweed uri> uri> James uri> uri> --- uri> uri> James Bottomley (2): uri> engine: add new flag based method for loading engine keys uri> pem: load engine keys uri> uri> crypto/engine/eng_int.h | 1 + uri> crypto/engine/eng_pkey.c | 38 ++++++++++++++++++++++++++++++++++++++ uri> crypto/engine/engine.h | 26 ++++++++++++++++++++++++++ uri> crypto/pem/pem_pkey.c | 5 +++++ uri> 4 files changed, 70 insertions(+) uri> uri> -- uri> openssl-dev mailing list uri> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev uri> -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev