[Rats] Comments on the changes of CHARRA YANG module

["Panwei (William)" <[e-mail]>]

Hi Eric,

I've read the YANG modules you changed, actually I didn't get how the new modules worked when I read it the first time. After reading it a few times and discussion with others, I kind of figured out how it worked:

1.     The Verifier (or Relying Party) uses the "rats-support-structures" datastore structure to retrieve the hardware information, i.e., all the compute-nodes and all the TPMs, from the Attester. Then the Verifier can establish the relationship between the TPM and its compute-node info and certificates info. Further, the Verifier can identify the TPM according to the certificate-name and/or the compute-node.

2.     Next, the Verifier uses the RPC structures to get Evidence in a challenge-response fashion. In the challenge input, the Verifier can use the leaf "key-identifier" to ask Evidence of one specific TPM based on this TPM's unique credential, or it can use the leaf-list "tpm-name" to ask Evidence of one or more TPMs based on these TPMs' names.

3.     In the response output, the Attester returns the Evidence. If the input contains only one TPM, then the output can match that TPM anyway. But if the input contains several "tpm-name", then the output is a set of Evidence of these TPMs, in this situation, the Verifier needs to use the "certificate-name" and/or "node-id" in each Evidence to identify which TPM produced it.

If my understanding is right, then the YANG modules after changed have some assumptions which aren't explicitly said, I conclude them below:

1.     The Verifier must retrieve the datastore first before initiate the challenge request.

2.     Every TPM should have a unique name, at least be unique in an Attester.

3.     Every certificate should have a unique name. It should be unique in an Attester if the certificate-name can identify the TPM, or should be unique in a compute node if the certificate-name and the node-id are used together to identify the TPM.

4.     For the input, if you choose to use the "key-identifier", then the list-leaf "tpm-name" must have only one value.
My suggestion would be to have a section to describe the workflow or the example of how to use this YANG module. Also, explicitly pointing out the assumptions would be much better.

Generally, I agree with the idea that don't use nested keys to identify the TPM (and its position) in RPCs. This has a significant benefit of scalability. Because if in the future more dimensions are needed to identify the TPM (and its position), the RPC structures don't need to be changed, only modifying the datastore structure is enough. But the current RPCs also have a disadvantage that the key is very obscure and implicit, for example, you need to use "certificate-name" and "node-id" as the key in the output. I suggest that we can just use the "tpm-name" as the key of output. Two advantages would be: easier for readers to understand, the Verifier doesn't need to search the database to find out the matched TPM.

Other comments:

1.     Some elements in the "rats-support-structures" are changed from read-only to read-write, e.g., the "supported-algos" and "certificates" of TPM. Why these elements can be configured now?

2.     The outputs of RPC "tpm12-challenge-response-attestation" and "tpm20-challenge-response-attestation" contains the "node-id" and "node-physical-index". Can these two elements be omitted in the output? Because they can be get through the datastore.

3.     The output of RPC "log-retrieval" doesn't contain the "node-id" or "node-physical-index", and this is different with the outputs of other two RPCs. I wonder whether here is right and other two RPCs need to delete the two elements.

Regards & Thanks!
Wei Pan