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.102...@ll.mit.edu> on Mon, 21 Nov 2016 13:50:43 +0000, "Blumenthal, Uri - 0553 - MITLL" <u...@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@openssl.org uri> Reply To: openssl-dev@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 -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
