On Wed, 2018-10-03 at 13:00 +0200, James Bottomley wrote: > On October 3, 2018 12:47:15 PM CEST, David Woodhouse wrote: > > On Wed, 2018-10-03 at 12:40 +0200, James Bottomley wrote: > > > > --- a/src/tpm2-tss-engine-common.h > > > > +++ b/src/tpm2-tss-engine-common.h > > > > @@ -55,8 +55,7 @@ TSS2_RC init_tpm_key(ESYS_CONTEXT **ctx, ESYS_TR > > > > *keyHandle, > > > > .objectAttributes = (TPMA_OBJECT_USERWITHAUTH | \ > > > > TPMA_OBJECT_RESTRICTED | \ > > > > TPMA_OBJECT_DECRYPT | \ > > > > - TPMA_OBJECT_FIXEDTPM | \ > > > > - TPMA_OBJECT_FIXEDPARENT | \ > > > > + TPMA_OBJECT_NODA | \ > > > > > > This is the only troubling change, the rest looks fine to me. The > > > template for a TPM created key *must* contain those two flags. NODA is > > > one of those things which should be specified on the command line > > > rather than hard coded as well. So to be exact, you need an extra > > > command line flag for whether or not you want TPMA_OBJECT_NODA (some > > > keys would like DA protection, especially private VPN ones, but the > > > creator of the key should ultimately decide) and if you have a TPM > > > create key you need TPMA_OBJECT_FIXEDTPM and TPMA_OBJECT_FIXEDPARENT > > > but if you're wrapping an existing key they have to be clear. > > > > This is for generating the primary key. It looks like your code always > > sets NODA, but *not* FIXEDTPM and FIXEDPARENT. > > > > The tpm2-tss engine does set FIXEDTPM and FIXEDPARENT, but not NODA. > > > > As noted, the above patch comes from blindly making tpm2-tss-engine > > look like your code, without even looking at what the flags mean :) > > > > I don't see why you set NODA on the primary key which has no auth > > anyway, and you seem to be saying that the lack of FIXED{TPM,PARENT} on > > your side is also problematic? > > For createprimary, noda is correct because it has no password. Let > me check the fixeds. The primary should have them. I'm boarding in > Paris at the moment but will check in-flight. > > > Does that mean we should be changing > > your code to match what's in tpm2-tss-engine? > > I think for the fixeds yes but likely it doesn't matter for the > primary because it will be assumed. 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 )