keyrings.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <jejb@linux.ibm.com>
To: Coly Li <colyli@suse.de>, Stefan Berger <stefanb@linux.ibm.com>
Cc: keyrings@vger.kernel.org, linux-kernel@vger.kernel.org,
	Dan Williams <dan.j.williams@intel.com>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	Mimi Zohar <zohar@linux.ibm.com>
Subject: Re: [PATCH RESEND] docs: update trusted-encrypted.rst
Date: Sun, 16 Aug 2020 17:08:19 +0000	[thread overview]
Message-ID: <1597597699.8344.11.camel@linux.ibm.com> (raw)
In-Reply-To: <096636f4-a928-dd00-dba6-216651c3d63b@suse.de>

On Mon, 2020-08-17 at 01:01 +0800, Coly Li wrote:
> On 2020/8/17 00:06, Stefan Berger wrote:
> > On 8/15/20 3:51 AM, Coly Li wrote:
[...]
> > >     Usage::
> > > @@ -115,7 +114,7 @@ append 'keyhandle=0x81000001' to statements
> > > between quotes, such as
> > 
> > 
> > A note in this file states this:
> > 
> > Note: When using a TPM 2.0 with a persistent key with handle
> > 0x81000001, append 'keyhandle=0x81000001' to statements between
> > quotes, such as "new 32 keyhandle=0x81000001".
> > 
> > Now if someone was (still) interested in TPM 1.2 then the below
> > changes you are proposing wouldn't work for them. Maybe you should
> > adapt the note to state that these keyhandle=... should be removed
> > for the TPM 1.2 case.
> > 
> 
> I agree. Indeed I have no idea why number 0x81000001 is used, and I
> don't have practice experience with TPM 1.2. Now the purpose of this
> patch accomplished: experts response and confirm my guess :-)

It was the conventional persistent value for the RSA 2048 version of
the primary storage seed.  Originally the PC spec required the
manufacturer provision this on all TPM 2.0 based PC class systems. 
Unfortunately in spite of it being in the Windows Hardware guide no
manufacturer ever did, meaning you either have to create it yourself or
do something different.  Because of usability problems, every consumer
of TPM key function has opted to do something different, namely derive
the EC primary if no parent is specified.

James

  reply	other threads:[~2020-08-16 17:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-15  7:51 [PATCH RESEND] docs: update trusted-encrypted.rst Coly Li
2020-08-15 12:46 ` colyli
2020-08-16 16:06 ` Stefan Berger
2020-08-16 16:36   ` James Bottomley
2020-08-16 16:57     ` Coly Li
2020-08-16 17:12       ` James Bottomley
2020-08-16 17:15         ` Coly Li
2020-08-18 15:44         ` Jarkko Sakkinen
2020-08-18 16:19           ` James Bottomley
2020-08-19 21:01             ` Jarkko Sakkinen
2020-08-16 17:01   ` Coly Li
2020-08-16 17:08     ` James Bottomley [this message]
2020-08-16 17:22       ` Coly Li
2020-08-16 17:05   ` Coly Li

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=1597597699.8344.11.camel@linux.ibm.com \
    --to=jejb@linux.ibm.com \
    --cc=colyli@suse.de \
    --cc=dan.j.williams@intel.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stefanb@linux.ibm.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).