On Thu, 2019-03-14 at 10:50 -0700, James Bottomley wrote:
On Thu, 2019-03-14 at 09:57 -0700, David Woodhouse wrote:
> On Thu, 2019-03-14 at 09:27 -0700, James Bottomley wrote:
> > On Thu, 2019-03-14 at 09:19 -0700, Andersen, John wrote:
> > > On Wed, Mar 13, 2019 at 04:56:17PM -0700, David Woodhouse wrote:
> > > > Here's a quick hack to make it work by abusing the OpenSC
> > > > engine config, as a proof of concept. Making it work cleanly so
> > > > that it can be merged is left as an exercise for the reader, or
> > > > perhaps an interested party in one of the mailing lists I've
> > > > added to Cc.
> > Well, you can't have the engine name hard coded ... that really
> > needs to be some type of parameter, which is going to be 99% of the
> > hassle making a proper patch ...
> And of course, it shouldn't have to be specified at all. If given a
> PEM file which happens to look like a TPM2 engine key, then the
> appropriate engine should be invoked automatically.
Hey don't beat me on the sore spot ...
This isn't really that hard to do in applications. For those using
OpenSSL it's just a case of making them recognise the appropriate
-----BEGIN string and invoke the engine appropriately.
Once my support gets merged into GnuTLS, it really can be automatic
with the application not having to do anything at all. OpenSSL might
get there too, once we have STORE support working in applications.
> Although if you just wanted to use those keys with GnuTLS, you
> have done that directly. I already ported it all except the new
> "importable" keys support.
Well, you know, using engines with gnutls does mean we don't have to
write the same code twice over ...
I'm not convinced that an OpenSSL ENGINE is the right form for
implementing this kind of thing in the general case. PKCS#11 is much
better as an existing portable standard, although it doesn't fit the
TPMv2 usage model very well.
Even OpenSSL is moving away from ENGINEs to a different plugin