On Thu, 2018-10-11 at 10:27 -0700, James Bottomley wrote:
> On Thu, 2018-10-11 at 15:41 +0000, Fuchs, Andreas wrote:
> > 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)
> 
> Actually, this is way too little.  In fact we don't care about the
> asymmetric key at all because it's the derived symmetric key that's
> used to encrypt the private blob (so you're missing its parameters). 
> Unfortunately the type and all the asymmetric parameters (including a
> lot you haven't show here) are part of the name which is input to KDFa
> for the symmetric key.  Let's just follow all the provisioning guidance
> because it does outline them in a table, so just say "The ECC Template
> from the EK and TPM provisioning guides".

That seems to make sense. Other than the objectAttributes, what else
have we done *differently* to the template in the provisioning guides?

> > For the On-Disk-Format:
> > We need to keep a placeholder for the (optional) policy I think.
> 
> We already have.  It's explicit element [3] of the key which is a
> sequence of TPMPolicy.  If you mean you want a different policy format,
> the elements of TPMPolicy are also explicits so they can be expanded.
> 
> > If we want to allow different formats in the future, we need to add
> > some idetifier for the format type in there as well.
> 
> It can be added later without disturbing the current format ... that's
> the point of ASN.1 EXPLICITs.

Ack.

> > 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 
> 
> To be honest perhaps the user shouldn't care about this: if they take
> the same key files, it's an implementation choice, not a fundamental
> one, so perhaps the user should simply decide on installation.

This stuff should JustWork™. People should be able to use any key they
happen to have — PKCS#11 URIs, files in various PEM and DER formats
including PKCS#12, PKCS#8, PKCS#1 and TSS blobs. I am utterly anal
about this in OpenConnect, and it *does* work for fairly much
everything under the sun. I've written this up in 
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html and
have started making at least Fedora packaging guidelines move in that
direction, saying that anything that takes a certificate+key SHOULD at
least accept PKCS#11 URIs. I should go further and incorporate the
whole of my draft, which also wants to be updated to talk about the new
TPM2 PEM format we're defining here.

So with that in mind... what advice do we give to application authors
to help them get this right? Remember, it actually needs to be hard for
them to get it *wrong*. The advice to actual users should always be "it
should Just Work. Else file bugs".

I think that having a single engine name, and having both engine
implementation install themselves to be loaded the same way, makes most
sense.