[Ming] Right, we didn't elaborate what triggers a TEEP Broker to contact TAM in this definition section. It was elaborated in the later section, for example, 4.3 where it says
" When a TEEP Broker receives a request (see the RequestTA API in Section 6.2.1) from an Untrusted Application to install a Trusted Component...".
This is the most common case where a TA is installed and provisioned via an UA. By this, the call to TAM is on-demand, not too many. On the other hand, there could be periodic policy checks with a TAM if an application designs to do so, which the architecture allows it and leave the choice to an application. Do you think the text is OK as is or would like to add a sentence to point the TEEP Broker triggering to the later sections in the definition?
I noticed this latter sentence; it was just not clear to me if this was meant to be the only use case, or if the architecture was meant to allow for broader management of TAs by TAMs in the future. I’ve got no issue with the “UA wants to install a TA” case, and for that the trigger was fine. But I was imaging a TAM wanting to proactively update TAs in the future and was concerned about polling. Perhaps I exceeded the scope of the protocol there!
[Ming] Agreed. Will update it to not lose the meaning that a constraint may be also in force. How about the following revision?
"The TAM is trusted by a device if the TAM's public key is, or
chains up to, an authorized Trust Anchor in the device, and conforms with all constraints defined in the Trust Anchor."
That is good.
/Bob
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
