deal with deep hole of assumed security properties

[mcr]

-- The overall Section 12 seems silent on:

o What is the implication of combining roles into a single entity as described in Section 3.4 and 6. Does this lack of separation present any additional issues?

[github said: https://github.com//issues/407]
==[ snip ]==
We need to acknowledge that there is a deep hole (not infinitely deep, but not trivial) where we need to look at integrity of all of the different platforms.
The way that the compositions are composed is a bit tricky, and the results are sometimes different than other people would naively assume.
Are there references here to other papers that we should include?
==[ snip ]==

I completely agree, that's why I mentioned it. Composition is hard and can alter the security assumptions of the individual components and introduce emergent risk.

I don't think it can be solved generically. However, we do need cautionary text here. Perhaps:

NEW (roughly)

The RATS architecture allows for an entity to function in multiple roles (Section 6) and for composite devices (Section 3.3). Implementers need to evaluate their designs to ensure that the assumed security properties of the individual components and roles still holds despite the lack of separation, and that emergent risk is not introduced. The specifics of this evaluation will depend on the implementation and use case is out of scope for this document.