Frankly, I think this approach of specially-encoded PEM or DER files telling the app what key to ask from the engine is madness, compared to the straightforward URI approach (no pun intended :).
Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: David Woodhouse Sent: Monday, November 21, 2016 08:43 To: Richard Levitte; openssl-dev@openssl.org Reply To: openssl-dev@openssl.org Cc: James Bottomley Subject: Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote: > > 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? Right. The TPM engine currently uses ----BEGIN TSS KEY BLOB-----; I added that a few years back (it used to just dump the binary blob instead). Both the TPM ENGINE and GnuTLS will load those files, as noted at http://www.infradead.org/openconnect/tpm.html The problem is that applications have to jump through special hoops to recognise the files and invoke the engine (and there's a special API in GnuTLS too). It would be good if the appropriate engine could be invoked *automatically*, so the crypto library just does the right thing without all the applications even having to *know* about it. (Just like GnuTLS will automatically Just Work in many situations when presented with a PKCS#11 URI instead a filename, as OpenSSL also should, but doesn't yet.) However, the contents of the PEM file should *not* be OpenSSL-specific and have engine names; I objected to James's original incarnation of this, which had something like -----BEGIN tpm ENGINE PRIVATE KEY----- and had the "tpm" engine automatically loaded on demand. It needs to be something generic. Which means engines need to indicate *which* PEM headers they can grok. And maybe the solution to this will tie in with the general fixes we need for "normal" key files, so that applications can Just Work with all of those too (qv¹). Once the dust settles on TPMv2.0 we should probably put together an I-D for the TPM-wrapped blob PEM files. And I should definitely add something about them to ¹. -- dwmw2 ¹ http://david.woodhou.se/draft-woodhouse-cert-best-practice.html
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev