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

[Richard Levitte]

I'm leaning in that direction as well.

Speaking of URIs, you might be interested in some work I did last
week, which would do good to get a bit of external scrutiny.

https://github.com/openssl/openssl/pull/1961 (for URI decoding)
https://github.com/openssl/openssl/pull/1962 (a STORE module that
essentially uses a URI and tries to fetch certs, keys, crls, ... from
it)

Please have a look.

Cheers,
Richard

In message <20161121135052.18280523.78584.102746 at ll.mit.edu> on Mon, 21 Nov 2016 13:50:43 +0000, "Blumenthal, Uri - 0553 - MITLL" <uri at ll.mit.edu> said:

uri> 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 :).
uri> 
uri> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
uri>   Original Message  
uri> From: David Woodhouse
uri> Sent: Monday, November 21, 2016 08:43
uri> To: Richard Levitte; openssl-dev at openssl.org
uri> Reply To: openssl-dev at openssl.org
uri> Cc: James Bottomley
uri> Subject: Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
uri> 
uri> On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote:
uri> > 
uri> > Many years ago, I was thinking of something along the same lines, but
uri> > with a .pem file that would just have a few headers, holding the name
uri> > of the intended engine and the key identity, something like this:
uri> > 
uri> >     -----BEGIN PRIVATE KEY-----
uri> >     X-key-id: flarflarflar
uri> >     X-key-engine: foo
uri> >     -----END PRIVATE KEY-----
uri> > 
uri> > The intent was that the PEM code would be massaged to recognise these
uri> > headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
uri> > with those data and that would be it.
uri> > 
uri> > James, did I catch your intention about right?  I think that's
uri> > essentially what e_tpm.c does for loading keys, right?
uri> ‎
uri> Right. The TPM engine currently uses ----BEGIN TSS KEY BLOB-----; I
uri> added that a few years back (it used to just dump the binary blob
uri> instead). Both the TPM ENGINE and GnuTLS will load those files, as
uri> noted at http://www.infradead.org/openconnect/tpm.html
uri> 
uri> The problem is that applications have to jump through special hoops to
uri> recognise the files and invoke the engine (and there's a special API in
uri> GnuTLS too). It would be good if the appropriate engine could be
uri> invoked *automatically*, so the crypto library just does the right
uri> thing without all the applications even having to *know* about it.
uri> (Just like GnuTLS will automatically Just Work in many situations when
uri> presented with a PKCS#11 URI instead a filename, as OpenSSL also
uri> should, but doesn't yet.)
uri> 
uri> However, the contents of the PEM file should *not* be OpenSSL-specific
uri> and have engine names; I objected to James's original incarnation of
uri> this, which had something like -----BEGIN tpm ENGINE PRIVATE KEY-----
uri> and had the "tpm" engine automatically loaded on demand. It needs to be
uri> something generic. Which means engines need to indicate *which* PEM
uri> headers they can grok. And maybe the solution to this will tie in with
uri> the general fixes we need for "normal" key files, so that applications
uri> can Just Work with all of those too (qv¹).
uri> 
uri> Once the dust settles on TPMv2.0 we should probably put together an I-D 
uri> for the TPM-wrapped blob PEM files. And I should definitely add
uri> something about them to ¹.
uri> 
uri> -- 
uri> dwmw2
uri> 
uri> ¹ http://david.woodhou.se/draft-woodhouse-cert-best-practice.html