Hi David,

thanks for the summary. I agree with all of them. Some more things to agree on:

Primarykeys.publicArea:
-  .type = TPM2_ALG_ECC, .nameAlg = TPM2_ALG_SHA256
- .objectAttributes = (TPMA_OBJECT_USERWITHAUTH | TPMA_OBJECT_RESTRICTED | TPMA_OBJECT_DECRYPT | TPMA_OBJECT_FIXEDTPM | TPMA_OBJECT_FIXEDPARENT | TPMA_OBJECT_SENSITIVEDATAORIGIN)

For the On-Disk-Format:
We need to keep a placeholder for the (optional) policy I think.
If we want to allow different formats in the future, we need to add some
idetifier for the format type in there as well.

Would you both agree ?

Regarding the engine naming:
Won't we run into a naming problem with the engine names if we name them similarly ?

P.S. The reason I did not call the engine "openssl-something-engine" is that this
is prohibited by the OpenSSL code license, unless openssl-core@ agrees, but
they never answered... ;-)

Cheers,
Andreas

________________________________________
From: David Woodhouse [dwmw2(a)infradead.org]
Sent: Monday, October 08, 2018 12:15
To: James Bottomley; Fuchs, Andreas; tpm2(a)lists.01.org; Nikos Mavrogiannopoulos
Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats


It would be good to reach a conclusion on what the PEM format should
be, so that I can push this to the OpenConnect master branch in
preparation for a release.

Let me attempt to summarise some of the discussions and create a
definition / TODO list.

 • We all change to use all three of NODA/FIXEDTPM/FIXEDPARENT
   objectAttributes for creating the primary key.

 • PEM file tag changes to 'BEGIN TSS2 PRIVATE KEY'. James can continue
   to use the old objectAttributes when loading files with the old PEM
   tag for compatibility reasons, if he wants to.

 • Drop the TPMv1.2 compatibility via '12Key' and the 'importableKey'
   object types, which in fact means we can drop the 'type' field from
   the ASN.1 definition altogether.

 • Make the pubkey field non-optional.

 • Ignore policy for now; we can define that later. We won't use the
   [3] EXPLICIT tag for anything incompatible with James's existing
   definition, and if we settle on something else we'll use a different
   explicit tag.

 • We produce a draft specifying the ASN.1 format and tpmkey: URI
   scheme.


That's probably enough for me to do a release of the GnuTLS code. On
the OpenSSL side I also recommend that:

 • Both engines should use the same engine name so that applications
   which match the PEM tag and load an engine don't have to try both.

 • Both engines should register the ASN.1 parser so that keys can be
   used transparently by applications without having to explicitly
   reference the engine at all (see
   https://github.com/openssl/openssl/issues/7354 )