Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <ff23b4e24222037959c2a784496c7ee91024e6c5.camel@linux.ibm.com>
Subject: Re: [PATCH v5 04/11] security: keys: trusted: Include TPM2 creation
 data
From:   James Bottomley <jejb@linux.ibm.com>
Reply-To: jejb@linux.ibm.com
To:     Eric Biggers <ebiggers@kernel.org>,
        Evan Green <evgreen@chromium.org>
Cc:     linux-kernel@vger.kernel.org, corbet@lwn.net,
        linux-integrity@vger.kernel.org, gwendal@chromium.org,
        dianders@chromium.org, apronin@chromium.org,
        Pavel Machek <pavel@ucw.cz>, Ben Boeckel <me@benboeckel.net>,
        rjw@rjwysocki.net, Kees Cook <keescook@chromium.org>,
        dlunev@google.com, zohar@linux.ibm.com,
        Matthew Garrett <mgarrett@aurora.tech>, jarkko@kernel.org,
        linux-pm@vger.kernel.org, David Howells <dhowells@redhat.com>,
        James Morris <jmorris@namei.org>,
        Paul Moore <paul@paul-moore.com>,
        "Serge E. Hallyn" <serge@hallyn.com>, keyrings@vger.kernel.org,
        linux-security-module@vger.kernel.org
Date:   Sun, 13 Nov 2022 22:32:00 -0500
In-Reply-To: <Y3FfhrgvBNey6T7V@sol.localdomain>
References: <20221111231636.3748636-1-evgreen@chromium.org>
         <20221111151451.v5.4.Ieb1215f598bc9df56b0e29e5977eae4fcca25e15@changeid>
         <Y3FfhrgvBNey6T7V@sol.localdomain>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Precedence: bulk

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