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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
