From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: linux-integrity@vger.kernel.org, Mimi Zohar <zohar@linux.ibm.com>,
David Woodhouse <dwmw2@infradead.org>,
keyrings@vger.kernel.org, David Howells <dhowells@redhat.com>
Subject: Re: [PATCH v13 4/5] security: keys: trusted: use ASN.1 TPM2 key format for the blobs
Date: Wed, 30 Sep 2020 15:35:04 +0000 [thread overview]
Message-ID: <20200930153504.GB52739@linux.intel.com> (raw)
In-Reply-To: <b8de8923e026525589c97b3cb7691a557c0a292f.camel@HansenPartnership.com>
On Wed, Sep 30, 2020 at 07:49:51AM -0700, James Bottomley wrote:
> On Wed, 2020-09-30 at 14:11 +0300, Jarkko Sakkinen wrote:
> > On Mon, Sep 21, 2020 at 07:28:08PM -0700, James Bottomley wrote:
> > > Modify the TPM2 key format blob output to export and import in the
> > > ASN.1 form for TPM2 sealed object keys. For compatibility with
> > > prior trusted keys, the importer will also accept two TPM2B
> > > quantities representing the public and private parts of the
> > > key. However, the export via keyctl pipe will only output the
> > > ASN.1 format.
> > >
> > > 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). The format
> > > includes policy specifications, thus it gets us out of having to
> > > construct policy handles in userspace and the format includes the
> > > parent meaning you don't have to keep passing it in each time.
> > >
> > > This patch only implements basic handling for the ASN.1 format, so
> > > keys with passwords but no policy.
> > >
> > > Signed-off-by: James Bottomley <
> > > James.Bottomley@HansenPartnership.com>
> >
> > I did the test for 3/5 with this patch applied (actually all patches
> > in this series) so I can safely
> >
> > Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> >
> > I have one wish though before giving reviewed-by.
> >
> > In my recent trusted keys fixes I took the convention trusted_tpm_*
> > for TPM trusted keys functions. I think we should start doing that
> > for all functions:
> >
> > 1. For interface functions trusted_tpm_*
> > 2. TPM1: trusted_tpm1_*
> > 2. TPM2: trusted_tpm2_*
>
> I'm not such a fan of this: we've discussed moving some of the
> functions around because we expect to grow consumers. We really don't
> want to be having to rename everything as we move it, so I'd far prefer
> the name were related to the function rather than the location in the
> kernel tree.
OK, I see you point here. The trusted_tpm_* functions that I added are
directly bound to the specifict trusted keys implementation, so it is
a different situation.
> > This is to manage chaos with TEE Trusted Keys in future and make the
> > distinction with TPM subsystem functions, and make it easier to grep
> > and trace this stuff with the various tracing tools.
> >
> > This anyway needs one more rebase on top of the fixes that I did.
> >
> > BTW, what is the situation with the ARM compilation issue?
>
> It was fixed in this incarnation.
OK, great.
/Jarkko
WARNING: multiple messages have this Message-ID (diff)
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: linux-integrity@vger.kernel.org, Mimi Zohar <zohar@linux.ibm.com>,
David Woodhouse <dwmw2@infradead.org>,
keyrings@vger.kernel.org, David Howells <dhowells@redhat.com>
Subject: Re: [PATCH v13 4/5] security: keys: trusted: use ASN.1 TPM2 key format for the blobs
Date: Wed, 30 Sep 2020 18:35:04 +0300 [thread overview]
Message-ID: <20200930153504.GB52739@linux.intel.com> (raw)
In-Reply-To: <b8de8923e026525589c97b3cb7691a557c0a292f.camel@HansenPartnership.com>
On Wed, Sep 30, 2020 at 07:49:51AM -0700, James Bottomley wrote:
> On Wed, 2020-09-30 at 14:11 +0300, Jarkko Sakkinen wrote:
> > On Mon, Sep 21, 2020 at 07:28:08PM -0700, James Bottomley wrote:
> > > Modify the TPM2 key format blob output to export and import in the
> > > ASN.1 form for TPM2 sealed object keys. For compatibility with
> > > prior trusted keys, the importer will also accept two TPM2B
> > > quantities representing the public and private parts of the
> > > key. However, the export via keyctl pipe will only output the
> > > ASN.1 format.
> > >
> > > 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). The format
> > > includes policy specifications, thus it gets us out of having to
> > > construct policy handles in userspace and the format includes the
> > > parent meaning you don't have to keep passing it in each time.
> > >
> > > This patch only implements basic handling for the ASN.1 format, so
> > > keys with passwords but no policy.
> > >
> > > Signed-off-by: James Bottomley <
> > > James.Bottomley@HansenPartnership.com>
> >
> > I did the test for 3/5 with this patch applied (actually all patches
> > in this series) so I can safely
> >
> > Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> >
> > I have one wish though before giving reviewed-by.
> >
> > In my recent trusted keys fixes I took the convention trusted_tpm_*
> > for TPM trusted keys functions. I think we should start doing that
> > for all functions:
> >
> > 1. For interface functions trusted_tpm_*
> > 2. TPM1: trusted_tpm1_*
> > 2. TPM2: trusted_tpm2_*
>
> I'm not such a fan of this: we've discussed moving some of the
> functions around because we expect to grow consumers. We really don't
> want to be having to rename everything as we move it, so I'd far prefer
> the name were related to the function rather than the location in the
> kernel tree.
OK, I see you point here. The trusted_tpm_* functions that I added are
directly bound to the specifict trusted keys implementation, so it is
a different situation.
> > This is to manage chaos with TEE Trusted Keys in future and make the
> > distinction with TPM subsystem functions, and make it easier to grep
> > and trace this stuff with the various tracing tools.
> >
> > This anyway needs one more rebase on top of the fixes that I did.
> >
> > BTW, what is the situation with the ARM compilation issue?
>
> It was fixed in this incarnation.
OK, great.
/Jarkko
next prev parent reply other threads:[~2020-09-30 15:35 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-22 2:28 [PATCH v13 0/5] TPM 2.0 trusted key rework James Bottomley
2020-09-22 2:28 ` James Bottomley
2020-09-22 2:28 ` [PATCH v13 1/5] lib: add ASN.1 encoder James Bottomley
2020-09-22 2:28 ` James Bottomley
2020-09-22 2:28 ` [PATCH v13 2/5] oid_registry: Add TCG defined OIDS for TPM keys James Bottomley
2020-09-22 2:28 ` James Bottomley
2020-09-22 2:28 ` [PATCH v13 3/5] security: keys: trusted: fix TPM2 authorizations James Bottomley
2020-09-22 2:28 ` James Bottomley
2020-09-25 7:28 ` Jarkko Sakkinen
2020-09-25 7:28 ` Jarkko Sakkinen
2020-09-25 17:39 ` James Bottomley
2020-09-25 17:39 ` James Bottomley
2020-09-27 23:48 ` Jarkko Sakkinen
2020-09-27 23:48 ` Jarkko Sakkinen
2020-09-30 11:02 ` Jarkko Sakkinen
2020-09-30 11:02 ` Jarkko Sakkinen
2020-09-22 2:28 ` [PATCH v13 4/5] security: keys: trusted: use ASN.1 TPM2 key format for the blobs James Bottomley
2020-09-22 2:28 ` James Bottomley
2020-09-26 11:33 ` kernel test robot
2020-09-26 11:33 ` kernel test robot
2020-09-26 11:33 ` kernel test robot
2020-09-30 11:11 ` Jarkko Sakkinen
2020-09-30 11:11 ` Jarkko Sakkinen
2020-09-30 14:49 ` James Bottomley
2020-09-30 14:49 ` James Bottomley
2020-09-30 15:35 ` Jarkko Sakkinen [this message]
2020-09-30 15:35 ` Jarkko Sakkinen
2020-09-22 2:28 ` [PATCH v13 5/5] security: keys: trusted: Make sealed key properly interoperable James Bottomley
2020-09-22 2:28 ` James Bottomley
2020-09-30 11:24 ` Jarkko Sakkinen
2020-09-30 11:24 ` Jarkko Sakkinen
2020-09-30 3:43 ` [PATCH v13 0/5] TPM 2.0 trusted key rework Jarkko Sakkinen
2020-09-30 3:43 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200930153504.GB52739@linux.intel.com \
--to=jarkko.sakkinen@linux.intel.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.