Coordinate TA updates with UA

[dmwheel1]

Issue was brought up in the WG meeting in Bangkok.

If the TAM updates a TA in a device, the update might break compatibility withe the UA (untrusted app)
In some cases (many cases) the change to the TA will require a commensurate change in the UA.
The text needs to be changed so that there is cooperation between the update in the TA and UA.

Since all things are triggered from the client device (not the TAM), the update of the TA should be trigger when the UA is updated and get the appropriate most updated TA that complies with the needs of the application.

The other concern has to do with a TA that is bound to multiple different UAs, and one requires a certain (newer) version, and another UA still requires the older version. This needs to be handled as well.

[hannestschofenig]

Related to issue #13

[hannestschofenig]

If we re-use the IETF SUIT update mechanism then dependencies are explicitly addressed. We would have to provide an example in the OTrP spec to explain this, of course.

In terms of text I think the following paragraph could be added to the architecture document:

---

TAs are software components that are used by one or more client applications. Client applications typically may have strict requirements about the TA version they can interact with. For this reason it is important to ensure that software updates by a TAM take into account the version expected by a client application. Likewise an updated client application may demand an upgrade of the version of a TA.

When a single TA is used by multiple client applications then updates of TAs as well as of the individual client applications need to take version dependencies into account.

For update of TAs this framework relies on the use of the IETF SUIT manifest format, which is able to express dependencies between different software versions.

---

[dthaler]

Regarding the above proposed text, it's not so much "TA version" per se as API contract, unless the Untrusted App has a way of getting the actual TA version even if the API contract (i.e., what syntax and symantics are exposed to the Untrusted App) is unchanged. And this is the same issue as any OS update, or any shared library update. Here is a proposed rewording:

For update of TAs this framework relies on the use of the IETF SUIT manifest format, which is able to express dependencies between different software components and versions. That is, dependencies from TAs on other TEE components can be expressed in a SUIT manifest, including dependencies on any other TAs, or trusted OS code (if any), or trusted firmware. Updating a TA may cause compatibility issues with any Untrusted Applications or other components that depend on the updated TA, just like updating the OS or a shared library could impact an Untrusted Application. Thus, an implementation needs to take into account such issues.

[dthaler]

@ncamwing this issue is now ready to be closed based on #75 being merged