On Sun, Nov 13, 2022 at 7:32 PM James Bottomley <jejb at linux.ibm.com> wrote:
>
> On Sun, 2022-11-13 at 13:20 -0800, Eric Biggers wrote:
> > On Fri, Nov 11, 2022 at 03:16:29PM -0800, Evan Green wrote:
> > > diff --git a/security/keys/trusted-keys/tpm2key.asn1
> > > b/security/keys/trusted-keys/tpm2key.asn1
> > > index f57f869ad60068..608f8d9ca95fa8 100644
> > > --- a/security/keys/trusted-keys/tpm2key.asn1
> > > +++ b/security/keys/trusted-keys/tpm2key.asn1
> > > @@ -7,5 +7,18 @@ TPMKey ::= SEQUENCE {
> > > emptyAuth [0] EXPLICIT BOOLEAN OPTIONAL,
> > > parent INTEGER ({tpm2_key_parent}),
> > > pubkey OCTET STRING ({tpm2_key_pub}),
> > > - privkey OCTET STRING ({tpm2_key_priv})
> > > + privkey OCTET STRING ({tpm2_key_priv}),
> > > + ---
> > > + --- A TPM2B_CREATION_DATA struct as returned from the
> > > TPM2_Create command.
> > > + ---
> > > + creationData [1] EXPLICIT OCTET STRING OPTIONAL
> > > ({tpm2_key_creation_data}),
> > > + ---
> > > + --- A TPM2B_DIGEST of the creationHash as returned from the
> > > TPM2_Create
> > > + --- command.
> > > + ---
> > > + creationHash [2] EXPLICIT OCTET STRING OPTIONAL
> > > ({tpm2_key_creation_hash}),
> > > + ---
> > > + --- A TPMT_TK_CREATION ticket as returned from the
> > > TPM2_Create command.
> > > + ---
> > > + creationTk [3] EXPLICIT OCTET STRING OPTIONAL
> > > ({tpm2_key_creation_tk})
> > > }
> >
> > The commit that added this file claimed:
> >
> > "The benefit of the ASN.1 format is that it's a standard and
> > thus the
> > exported key can be used by userspace tools
> > (openssl_tpm2_engine,
> > openconnect and tpm2-tss-engine"
> >
> > Are these new fields in compliance with whatever standard that was
> > referring to?
>
> Not really, no. The current use case (and draft standard) is already
> using [1] for policies and [2] for importable keys:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/tree/doc/draft-bottomley-tpm2-keys.xml
>
> I'm actually planning to use [3] for signed policies. There's no
> reason why you can't use [4] though. Since the creation data, hash and
> ticket are likely used as a job lot, it strikes me they should be a
> single numbered optional sequence instead of individually numbered,
> since you're unlikely to have one without the others.
Thanks, I was hoping James might pipe up and tell me what to do.
Grouping them as a single numbered optional sequence sounds reasonable
to me. Is your draft too far along to squeeze this in? If it is and
I'm on my own to draft up and submit this, I would definitely
appreciate any pointers on getting started you might have.
I notice the draft and the code seem to be out of alignment. I'm
unfamiliar with this process, is the idea to get through all the
iterations and land the standard, then fix up the code? What happens
to existing data handed out in the old format?
-Evan