Define Standardized Handles

[kathrynfejer]

While attempting to run an XTT handshake outside of the tool and XTT's C library, we found that handles have not been standardized for the library.

[drbild]

These should be added to the RFC as well, in a section on TPM usage. (Or perhaps a separate RFC that defines how to use a TPM with the XTT spec.)

[zanebeckwith]

I'm not convinced these should be standardized.

Yes, at the least, we should set these values as defaults, to avoid having to specify each one on the command line.

But I'm not sure that an RFC should specify these values. These are user-specific (analogous to the file path to a private key file), rather than an agreed-upon value necessary for interop with other implementations or other parties (e.g. the value of a constant that appears in a message).

The handles currently used just happen to be what we at Xaptum are using for provisioning the TPMs we create. Another client could provision their TPMs differently and run XTT with no change apparent to the server or other clients.

Leaving these unspecified allows the off chance that someone is already using a particular handle for some other use.

[drbild]

Yes, at the least, we should set these values as defaults, to avoid having to specify each one on the command line.

The main driver here isn't the tools provided by this repo (CLI). It's custom software integrating the XTT library (like enftun or @iguberman 's simulation clients.) Those need the "defaults" as well.

But I'm not sure that an RFC should specify these values. These are user-specific (analogous to the file path to a private key file), rather than an agreed-upon value necessary for interop with other implementations or other parties (e.g. the value of a constant that appears in a message).

The handles currently used just happen to be what we at Xaptum are using for provisioning the TPMs we create. Another client could provision their TPMs differently and run XTT with no change apparent to the server or other clients.

Except that there are two parties involved. One (Xaptum) doing the TPM provisioning and another (the customer) running XTT. A pair needs to agree on a set of handles.

Each pair negotiating individually won't scale. It'd be easier if the issuer (Xaptum) can simply advertise "RFC WXYZ-compliant` TPMs. Or the customer can simply request "RFC WXYZ-compliant" TPMs.

No one is forced to comply with that standard if they want to negotiate different handles and deal with the associated ramifications.

[drbild]

The TCG Technical Committee will assign global handles to component, TPM, and platoform OEMs for specific purposes (see page 4). That could be a good route to pursue, instead of an RFC. Of course, the exact objects and formats to store need to be resolved first (issue #78).

In the short term, I advocate for merging #76. That makes XTT usage much simpler for the current users. The handles are in the "free-for-all" address space [1], so we won't conflict with a future reserved handle.

[1] "An NV index assigned by an entity outside TCG does not have the same meaning in all
platforms." (Registry_ of reserved TPM 2.0 handles and localities. Page 4, Par 1.)

[zanebeckwith]

Yes, I agree that the TCG route makes more sense than an RFC, especially not included in the main XTT RFC.

And, yes, making this part of the public API of this project is a good idea.

I'll take a look at PR #76