hierarchy: support platform

[williamcroberts]

No description provided.

[williamcroberts]

I guess if you use a persistent key it should work, so think this through.

[AndreasFuchsTPM]

For any newcomers that wanna help, here's my notes I made for a rainy winter night
(mixed with fapi_external key thoughts)

I'd extend struct tobject with

enum tobject_type = { ttype_default, ttype_persistent_handle, (ttype_fapi_path in the future) }

union {
    struct {
        twist pub;           /** public tpm data */
        twist priv;          /** private tpm data */
        uint32_t tpm_handle;     /** loaded tpm handle */
    };
    uint32_t persistent_handle;
    struct {
        char *fapi_path; (in the future)
        uint32_t tpm_handle;     /** loaded tpm handle */
    };
};

Then extend the yaml-de-/serializer (using ttype_default as default).

Then all access to pub and priv can be omitted in case of ttype_persistent_handle (Or switched to Fapi_GetTpmBlob in case of ttype_fapi)

And all access to tpm_handle can be set to persistent_handle in case of ttype_persistent_handle

[williamcroberts]

I don't see how that fits into this... perhaps ill grok it better verbally.

[AndreasFuchsTPM]

Sorry, those were some thoughts on peristent keys and FAPI keys. If they don't fit, please ignore.

[williamcroberts]

Sorry, those were some thoughts on peristent keys and FAPI keys. If they don't fit, please ignore.

Ahh context makes more sense. I was the context of primary keys in the hierarchy. But yeah, I guess a persistent subordinate key object could be useful and generally make the token quicker.