[cryptonector]

Not a dumb question!

The "TPM 2.0 Library part 1: Architecture" spec[0], section 23.2, describes the hierarchical relationships between objects.

A child of a derivation parent is derived from the parent, and can be re-derived as needed, therefore it doesn't need to be wrapped. A child of a storage key is wrapped in [a symmetric key derived from a seed associated with] that key.

There are also two cryptographic names for each object, one that includes the parent's cryptographic name in the child's name, and one that does not.

  [0] https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf

[cryptonector]

I should add that the main reason for this distinction between derivation and storage parents is that for keys generated on the TPM where you find them you just don't have to wrap those keys when you generate them as derived from [ultimately the hierarchy's seed] and a template, but that option is not available when importing keys generated elsewhere. The latter is called 'key duplication'. An entity can create a TPM2_Duplicate() [0] output payload encrypted to a TPM's key that the TPM can then TPM2_Import() then TPM2_Load(), and then that key at that target TPM cannot have a derivation parent since it isn't derived from any key on that TPM, therefore the only way to keep it around is to wrap it in some other key on that TPM, and that's where the storage keys come in.

  [0] In software, or on another TPM where the
      key being duplicated is not fixedTPM and
      fixedParent.  Yes, one can generate keys
      on a TPM that can be extracted or sent to
      specific other TPMs, or not at all, at
      the user's choice.  Which means that one
      can set up a ring of TPMs to hold a given
      key, for example.  I.e., TPMs can
      function as HSMs.