Re: tpm2key.asn1 parent identification

On Tue, 2025-09-23 at 17:25 +0300, Jarkko Sakkinen wrote:
> On Mon, Sep 22, 2025 at 05:31:24PM -0400, James Bottomley wrote:
> > On Mon, 2025-09-22 at 11:56 +0300, Jarkko Sakkinen wrote:
> > > On Thu, Sep 18, 2025 at 08:35:38PM +0300, Jarkko Sakkinen wrote:
[...]
> > > > The way I see it, a "random project" would apply to any project
> > > > that a format is locked in, and it is quite obvious that fixing
> > > > handle as the anchor is exactly fit for exactly for this
> > > > project, and within those exact limits it is probably a
> > > > sustainable choice.
> > > >=20
> > > > Being able to fix key into cryptographic=C2=A0 identity is somewhat
> > > > sane addition because not only does it lock-in the creator but
> > > > it also allows to use offline stored keys with the same scheme
> > > > i.e., non-endorsement hierarchy derived keys created with
> > > > TPM2_Create or TPM2_Import.
> > > >=20
> > > > In the context of OpenSSL TPM2 engine, perhaps the current
> > > > scheme is fine but in the context of supporting a "ecosystem"
> > > > as a kernel feature it's not in its current form robust enough.
> > > >=20
> > > > And how else I can describe it other than I don't care about
> > > > the project, if the file format enforces me align with it?
> > >=20
> > > The ASN.1 definition limits types of keys while there's no any
> > > good reasons to disregard transient keys.=20
> >=20
> > As I explained in the bit you quote above, the spec covers volatile
> > parents.
> >=20
> > > It also enforces handle numbers, which is not very robust
> > > approach.
> >=20
> > I think if you read the spec, you'll find it only requires handle
> > numbers for persistent keys ... specific handle numbers being a
> > feature of those keys required by TPM spec.
> >=20
> > > I've neither seen any cryptographic object in my life, which uses
> > > ambiguous data as part of the identity no matter how hypothetical
> > > the possible threat scenarios are. It's a bad security practice
> > > plain and simple.
> >=20
> > This contains no actionable technical content.=C2=A0 However, it is
> > possible the spec doesn't cover your use case, it's just you
> > haven't actually outlined what your use case is, so no-one who
> > knows the spec can actually confirm or deny this.
>=20
> I revisited the issue and this is how I see the situation.
>=20
> I think the most feasible approch especially for volatile keys would
> be to store all structures included in TPM2_Create response, instead
> of only storing the first two response parameters. Rest of the blobs
> can be e.g. optional. It's the most bottleneck free way to address
> any issues.

I still don't understand what issues you're referring to.  However ...

> Creation data contains indefinitive information about parent and this
> also enable the use of tickets.

This is already being discussed on the list if you want to join:

https://groups.io/g/openssl-tpm2-engine/topic/patch_doc_update_draft_rfc/11=
5384542

Regards,

James