On Thu, 2018-10-11 at 21:40 +0200, Nikos Mavrogiannopoulos wrote:
> On Thu, Oct 11, 2018 at 8:48 PM David Woodhouse <dwmw2(a)infradead.org>
> wrote:
> > On Thu, 2018-10-11 at 20:41 +0200, Nikos Mavrogiannopoulos wrote:
> > > As a distribution representative for rhel/fedora, I really second
> > > that. There is no reason to create code for auto-detection as a
> > > typical application writer or app user would want to use "tpm2"
> > > rather a specific engine. In fact we are even hiding the engine
> > > loading when we can as this is a detail the user shouldn't
> > > bother.
> > 
> > In an ideal world I'd go even further and suggest we should have
> > just one engine — all the ASN.1 parsing and OpenSSL interfacing,
> > and the STORE bits I'd like to add, could exist just once. Likewise
> > the policy parsing, in fact.
> > 
> > And the back end which actually talks to the TPM could have two
> > variants, for both TSS stacks. Much like the code I've put into
> > OpenConnect, which I'm hoping to palm off onto Nikos for GnuTLS...
> > :)
> 
> I'd really appreciate a PR!
>  

I haven't even pushed it to my own master branch yet :)

As well as finalising the discussion we're having here, I would very
much appreciate some review from James for 

http://git.infradead.org/users/dwmw2/openconnect.git/blob/tpm2:/gnutls_tpm2_ibm.c
and from Andreas for

http://git.infradead.org/users/dwmw2/openconnect.git/blob/tpm2:/gnutls_tpm2_esys.c

Going further with my fantasies about an ideal world, it would actually
be great to have a single "use a key from a TPM" library that has the
two implementations for each TSS, and is used *both* from a single
OpenSSL ENGINE implementation and also from GnuTLS....

Realistically speaking, I suspect we'll end up with separate but very
similar implementations as we have now. I'll settle for bashing heads
together and making sure they all interoperate and we publish the specs
in a sane form.