Re: tpm2key.asn1 parent identification

James Bottomley <[email protected]> Sun, 14 Sep 2025 23:24:24 -0400
Newsgroups dev.linux.lists.tpm2,org.kernel.vger.linux-integrity
Message-ID <6e1f2713288b48a1cc0311d01e281a98d8e7f45d.camel@HansenPartnership.com>
On Sun, 2025-09-14 at 19:08 +0300, Jarkko Sakkinen wrote:
> Hi,
>=20
> In practice, while implementing tpm2sh and its self-contained TPM
> emulator called "MockTPM", I've noticed that 'tpm2key.asn1.' has a
> major bottleneck, but luckily it is easy to squash.
>=20
> Parent handle should never be persisted, as it defies the existential
> reason of having a file format in the first place.

Actually, if you read the spec:it describes how to handle non-
persistent parents by defining the exact form of the P256 parent you
derive from the permanent handle in section 3.1.8:

https://www.hansenpartnership.com/draft-bottomley-tpm2-keys.html

This is the way all the implementations (well except the kernel, but
that's fixable) do it.

> To address this issue I just added couple of optional fields to
> TPMKey:
>=20
> =C2=A0 parentName=C2=A0=C2=A0 [6] EXPLICIT OCTET STRING OPTIONAL,
> =C2=A0 parentPubkey [7] EXPLICIT OCTET STRING OPTIONAL

So that's a bit redundant, since if you know the key, you know its
name.

> By persisting this information TPM2_GetCapability + TPM2_ReadPublic
> can be used to acquire an appropriate handle.

It can, how?  If the parent is a primary, you can't insert it from a
public key, you have to derive it and if it's non-primary, you need its
parent to do the insertion.

> I'd highly recommend to add this quirk to anything that processes
> this ASN.1 format.

Well, patches to the standard are accepted:

https://groups.io/g/openssl-tpm2-engine/topics

But first verify you don't simply need to use the non-persistent
format.

Regards,

James