linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: David Woodhouse <dwmw2@infradead.org>, linux-integrity@vger.kernel.org
Cc: Mimi Zohar <zohar@linux.ibm.com>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	keyrings@vger.kernel.org, David Howells <dhowells@redhat.com>
Subject: Re: [PATCH 0/4] Trusted Key policy for TPM 2.0
Date: Fri, 21 May 2021 08:55:32 -0700	[thread overview]
Message-ID: <25e874bfd1d33ebd2dc774b9ab2d47285a2f4d07.camel@HansenPartnership.com> (raw)
In-Reply-To: <646c272b64912d9d5c9c3c7fdc304ad01772365c.camel@infradead.org>

On Fri, 2021-05-21 at 16:22 +0100, David Woodhouse wrote:
> On Fri, 2021-05-21 at 07:28 -0700, James Bottomley wrote:
> > On Fri, 2021-05-21 at 14:48 +0100, David Woodhouse wrote:
> > > On Thu, 2021-05-20 at 17:43 -0700, James Bottomley wrote:
> > > > Now that the ASN.1 representation of trusted keys is upstream
> > > > we can add policy to the keys as a sequence of policy
> > > > statements meaning the kernel can now construct and use the
> > > > policy session rather than the user having to do it and pass
> > > > the session down to the kernel.  This makes TPM 2.0 keys with
> > > > policy much easier.
> > > > 
> > > > The format of the policy statements is compatible with the
> > > > openssl_tpm2_engine policy implementation:
> > > > 
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/
> > > > 
> > > > And the seal_tpm2_data command in the above can be used to
> > > > create sealed keys (including with policy statements) for the
> > > > kernel.
> > > 
> > > I'd love to see that format properly defined and documented
> > > instead of just a reference to another implementation.
> > 
> > Well if you want to help me write an RFC, I can try to submit it.
> 
> The xml2rfc tool makes it fairly easy.

XML and easy ... there's two words you don't often see in a sentence
...

> See https://github.com/dwmw2/ietf-cert-best-practice for a template;
> in Appendix B there is an example of specifying an ASN.1 format.

OK, I'll add it to 

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/

But I'll be expecting patches ...

> We should probably define not just the ASN.1 format but also a URI
> scheme for referencing objects in NVRAM. A TPMv2 version of 
> https://datatracker.ietf.org/doc/html/draft-mavrogiannopoulos-tpmuri-01
> might be a good idea.

I'm not so sure ... the keys are files not tokens and the pkcs11 URI
doesn't have a file pointer.  I suspect the correct way to represent
them would be to fully represent the key in the URI, which sounds like
a length explosion.

If you really want to use PKCS11 for TPM keys, I've actually got an
engine exporter for any openssl engine key:

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl-pkcs11-export.git/

So you can refer to them with standard PKCS11 URI components instead of
making your own up.  I use it for TPM keys in firefox for instance.

James



  reply	other threads:[~2021-05-21 15:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-21  0:43 [PATCH 0/4] Trusted Key policy for TPM 2.0 James Bottomley
2021-05-21  0:43 ` [PATCH 1/4] security: keys: trusted: add PCR policy to TPM2 keys James Bottomley
2021-05-22 22:38   ` Jarkko Sakkinen
2021-05-21  0:43 ` [PATCH 2/4] security: keys: trusted: add ability to specify arbitrary policy James Bottomley
2021-05-22 22:40   ` Jarkko Sakkinen
2021-05-21  0:44 ` [PATCH 3/4] security: keys: trusted: implement counter/timer policy James Bottomley
2021-05-21  0:44 ` [PATCH 4/4] security: keys: trusted: implement authorization policy James Bottomley
2021-05-21 13:48 ` [PATCH 0/4] Trusted Key policy for TPM 2.0 David Woodhouse
2021-05-21 14:28   ` James Bottomley
2021-05-21 15:22     ` David Woodhouse
2021-05-21 15:55       ` James Bottomley [this message]
2021-05-21 16:12         ` David Woodhouse
2021-05-21 16:17           ` James Bottomley
2021-05-21 17:53             ` David Woodhouse
2021-05-22 22:45   ` 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=25e874bfd1d33ebd2dc774b9ab2d47285a2f4d07.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=dhowells@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=jarkko@kernel.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 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).