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. :)