[PATCH v6 2/2] KEYS: trusted: Store parent's name to the encoded keys

[Jarkko Sakkinen]

On Sun, Dec 07, 2025 at 10:07:55PM +0200, Jarkko Sakkinen wrote:
> On Sun, Dec 07, 2025 at 07:57:13PM +0200, Jarkko Sakkinen wrote:
> > On Sun, Dec 07, 2025 at 07:32:10PM +0200, Jarkko Sakkinen wrote:
> > > Extend TPMKey ASN.1 speciication [1] with an optional 'parentName'
> > > attribute containing TPM name of the parent key (in other words, TPMT_HA
> > > blob).
> > > 
> > > The life-cycle for trusted keys will now proceed as follows:
> > > 
> > > 1. Encode parent's name to the 'paretName' during tpm2_key_encode().
> > > 2. During tpm2_unseal_trusted, read parent's name from 'parentName'. When
> > >    the attribute is not available, fallback on doing tpm2_read_public().
> > > 
> > > In other words, in the common (i.e., not loading a legacy key blob),
> > > tpm2_read_public() will now only happen at the time when a key is first
> > > created.
> > > 
> > > In addition, move tpm2_read_public() to 'tpm2-cmd.c' and make its body
> > > unconditional so that the binary format of the saved keys is not dependent
> > > on kernel configuration.
> > > 
> > > [1] https://www.hansenpartnership.com/draft-bottomley-tpm2-keys.txt
> > > 
> > > Cc: tpm2 at lists.linux.dev
> > > Signed-off-by: Jarkko Sakkinen <jarkko at kernel.org>
> > 
> > As an alternative workaround I think the following could be possibly
> > done (I need to trial it first though):
> > 
> > 1. Maintain a cache where a name gets added at the time of
> >    tpm2_seal_trusted(). It is from TPMT_HA to TPMT_HA mapping,
> >    mapping TPMT_HA of the key to the TPMT of the parent.
> > 2. At thet time tpm2_unseal_trusted() retrieve name of thet
> >    parent from the cache.
> > 
> > Capturing TPM2_CreatePrimary would be essentially duct taping the
> > spec but I guess this could be more generally applicable. It neither 
> > addresses persistent keys nor secondary parent keys, which we *have
> > to support*, as the kernel interface does.
> 
> I think it is better to focus on merging the first patch and continue
> this in the working groups mailing list first before implementing
> complex quirks to address flaws of the file format.

Storing the name of the parent to the key file has also some other
advantages such as enabling parent auto discovery, which is especially
useful with transient keys. Parent handle is not useful data as by
definition it has an ambiguous meaning.

It is neither "insecure" as child key is tied to one single parent but
at the same parent's handle is completely useless and irrelevant data.

There's nothing "niche" IMHO on storing parent's name at least, and
it is very limiting not to have it.

BR, Jarkko