On Fri, 2021-05-21 at 08:55 -0700, James Bottomley wrote:
> 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 ...

Absolutely :)

> > 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.

Not files, and definitely nothing to do with PKCS#11.

I meant a URI for referring to keys which are in NVRAM. The kind you
currently use the '//nvkey:' prefix for.

We should standardise that form, as a URI, so that users can take that
same URI to *any* application and expect it to work. That's what 
https://tools.ietf.org/html/draft-mavrogiannopoulos-tpmuri-01 was
doing, for TPMv1.2.