Just my opinion:

The TPM has very few persistent key slots.  They are typically reserved
for early boot when there is no other persistent storage.  Unless you have
a restricted application, like an appliance, try not to use persistent
keys because they may not be available.

Typically, keep your application's key on disk, load it when you need
it, and flush it when you're done or your application exits.

~~

Your understanding is correct - persistent keys are created by the owner,
a higher privileged role that will manage the few (perhaps 7 or less)
key slots.

There are probably complex schemes, forget the owner auth and use
an owner policy specific to each key.  But, unless you have an
appliance / embedded application, you don't control that.

> From: Ted Kim <ted.h.kim@oracle.com>

> To: tpm2@lists.01.org
> Date: 04/27/2021 12:38 PM
> Subject: [EXTERNAL] [tpm2] get TPM applications to happily co-exist
>
> Folks,
>
> The question has come up about how to get TPM applications to happily
> coexist with minimal coordination.
>
> One issue in the owner hierarchy is we want each application to to be
> able to manage it's own objects but not affect those of the other
> applications.
>
> So for example, we only want application A to be able to evict
> persistent handles owned by that application and not those of another
> application B.
>
> If I understand, tpm2_evictcontrol command, the authorization is on the
> hierarchy and not on the object. Maybe I am thinking about this wrong,
> but is there a way in the authorization to look at some property of the
> object and tell who "owns" it and then figure out if this should be
> allowed or not ?
>
> Otherwise, I think, we end up building some other software which knows
> how to authorize this on the hierarchy and keeps track of who owns what
> and then issues the eviction only when the owner of an object is the
> requester.
>
> Am open to any suggestions.
>
> Thanks,
> -ted
>
> _______________________________________________
> tpm2 mailing list -- tpm2@lists.01.org
> To unsubscribe send an email to tpm2-leave@lists.01.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>