On Mon, 2016-11-21 at 13:42 +0000, David Woodhouse wrote: > 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?
Yes, that's right. When any SSL program sees a TPM wrapped key, it should just do the right thing if it has the engine capability without needing the user to add any options to the command line. > 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¹). Right, I forgot to add in the blurb that I'm looking for a mechanism that all SSL implementations could follow, so it can't be tied to anything specific in openSSL (like the engine name). I modelled it on gnutls because that has the same "just works(tm)" characteristic that I was looking for. > 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 ¹. Once we agree, I'll be happy to write up something. We can use the pem header concept to extend this format if it becomes necessary. James
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev