On Mon, Nov 14, 2022 at 8:56 AM James Bottomley [off-list ref] wrote:

On Mon, 2022-11-14 at 08:32 -0800, Evan Green wrote:

quoted

On Sun, Nov 13, 2022 at 7:32 PM James Bottomley [off-list ref]
wrote:

quoted

On Sun, 2022-11-13 at 13:20 -0800, Eric Biggers wrote:

quoted

On Fri, Nov 11, 2022 at 03:16:29PM -0800, Evan Green wrote:

quoted

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?

Not at all.  The draft only becomes frozen once I submit it to the IETF
which, so far thanks to lack of any reviewers I haven't done (That's
why I was also thinking of adding signed policies).

quoted

 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.

The kernel code is out of alignment just because development moves a
bit slowly.  Policy based keys were submitted a long time ago as part
of the original move to interoperable sealed keys based on ASN.1:

https://lore.kernel.org/all/20200616160229.8018-7-James.Bottomley@HansenPartnership.com/ (local)

But eventually the policy part was split out and forgotten about.  I
think the only complete implementation of the draft standard is the
openssl_tpm2_engine.

quoted

 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?

No, it doesn't matter at all.  That's the whole point of using ASN.1
explicit optionals: the ASN.1 is always backwards compatible.  If I
ever submit the draft, there'll have to be a new RFC to add new
explicit optionals, but keys conforming to the old RFC will still be
valid under the new one.

Ah I see, with the optionals in mind things do line up again.

Of course, since openssl_tpm2_engine is the complete reference
implementation that means I'll have to add the creation PCRs
implementation to it ... unless you'd like to do it?

I am willing to help as I'm the one making the mess. How does it
sequence along with your draft submission (before, after,
simultaneous)?