FWIW I have the GnuTLS code also working, including with EC keys (and I
think I know how to tell GnuTLS not to ask me to do SHA512). I should
be able to adjust it to conform to whatever consensus we reach.

cf. https://tools.ietf.org/html/draft-mavrogiannopoulos-tpmuri-01


On Thu, 2018-10-04 at 16:04 +0000, Fuchs, Andreas wrote:
> Should we try to setup a wiki or markdown to start converging into a single form ?
> I think we can also easily set NODA for the primary, because they have to auth value anyways.
> 
> @James: how do you handle the key-ids ? Allways assume them to be files ?
> I have a PR for persistent TPM keys, where all key ids starting with 0x are interpreted as TPM keys.
> For the future I'll also want to reference FAPI keys (path-like format).
> Thus, any clues on how to handle things consistently here ?
> 
> tpm2-tss-engine will propably not support policies from your format then, but wait until FAPI (with integrated policy engine) is available.
> ________________________________________
> From: David Woodhouse [dwmw2(a)infradead.org]
> Sent: Wednesday, October 03, 2018 22:47
> To: James Bottomley; Fuchs, Andreas; tpm2(a)lists.01.org; Nikos Mavrogiannopoulos
> Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats
> 
> On Wed, 2018-10-03 at 11:35 +0100, David Woodhouse wrote:
> > 
> > 
> > Full patch below, for reference. Don't heckle too hard; it exists
> > mostly to document the current incompatibilities. I'll let the two of
> > you come to an agreement on the correct way to resolve them, while I
> > throw together some GnuTLS code to use the same PEM files.
> 
> OK... OpenConnect now supports both OpenSSL engines, and I've thrown
> together some GnuTLS code cribbing from tpm2-tss-engine, implementing a
> gnutls_privkey_t with some caveats (RSA only, PKCS#1 padding only,
> no auth, no policy, only the default parent, ...).
> 
> http://git.infradead.org/users/dwmw2/openconnect.git/blob/tpm2:/gnutls_tpm2_esys.c
> http://git.infradead.org/users/dwmw2/openconnect.git/blob/tpm2:/gnutls_tpm2.c
> 
> I'd love *not* to have to fix all those caveats, and for this to live
> in a library somewhere instead. :)