On Fri, Feb 19, 2021 at 10:35:00AM -0800, James Bottomley wrote: > On Fri, 2021-02-19 at 20:24 +0200, Jarkko Sakkinen wrote: > > On Wed, Jan 27, 2021 at 11:06:12AM -0800, James Bottomley wrote: > > > v15: fix 0day sign issue and add reviews and testeds > > > > > > General cover letter minus policy bit: > > > > > > This patch updates the trusted key code to export keys in the ASN.1 > > > format used by current TPM key tools (openssl_tpm2_engine and > > > openconnect). The current code will try to load keys containing > > > policy, but being unable to formulate the policy commands necessary > > > to > > > load them, the unseal will always fail unless the policy is > > > executed > > > in user space and a pre-formed policy session passed in. > > > > > > The key format is designed to be compatible with our two openssl > > > engine implementations as well as with the format used by > > > openconnect. > > > I've added seal/unseal to my engine so I can use it for > > > interoperability testing and I'll later use this for sealed > > > symmetric > > > keys via engine: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/ > > > > > > James > > > > > > --- > > > > > > James Bottomley (5): > > > lib: add ASN.1 encoder > > > oid_registry: Add TCG defined OIDS for TPM keys > > > security: keys: trusted: fix TPM2 authorizations > > > security: keys: trusted: use ASN.1 TPM2 key format for the blobs > > > security: keys: trusted: Make sealed key properly interoperable > > > > This is online again in the master branch. > > > > I've mangled the commits as follows: > > > > 1. Fixed my emails to jarkko@xxxxxxxxxx. > > 2. Adjusted the Makefile, i.e. separate lines for each entry. > > 3. Fixed the checkpatch issues. > > > > I guess we could potentially re-consider this to rc2 pull? With all > > the mangling required, did not make sense to include this to the > > first pull. > > The way I usually do this in SCSI, because stuff always happens > immediately before the merge window that causes some pull material to > be held over, is an early push, which you've done followed by a late > push on the Friday before the merge window closes of the rest of the > stuff. This is an example from the last but one merge window: > > https://lore.kernel.org/linux-scsi/fdee2336d2a7eada3749e07c3cc6ea682f8200b3.camel@xxxxxxxxxxxxxxxxxxxxx/ > https://lore.kernel.org/linux-scsi/4affd2a9c347e5f1231485483bf852737ea08151.camel@xxxxxxxxxxxxxxxxxxxxx/ > > Linus seems to be happy with this pattern as long as it's well > explained. > > James OK, thanks, I'll keep this in mind. /Jarkko
