[openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[James Bottomley]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5100 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161121/c6bef02a/attachment.bin>