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.
James
