Re: [Rats] Should we remove submods from EAT? (was Re: EAT Review Comments)

["Smith, Ned" <[e-mail]>]

[NMS](speaking not as chair)
--snip--
Here’s a few more reasons for submods:

- Complex devices like phones, routers and cars have a large number of subsystems. For the router case, you may have individual attestation from cards in the router and one for the chassis. A mobile phone has like 10 major compute environments (TEE, camera, modem, low power audio, CPU/GPU…) We need a way to express and organize claims for all sorts of complex devices.

[NMS] More correctly, the vendor community who creates the TEE, camera, modem, lp audio, CPU/GPU etc… need a way to express and originate claims for all sorts of complex devices. The presumed way to achieve this using CWT/JWT (that contains EAT claims) is that the ‘sub’ claim describes the ‘module’ and the ‘iss’ claim describes the vendor (although this isn’t specifically defined in the EAT draft. It is possible, using submod, to use the submod name ‘submods-label’ to refer to the component, which is a component of the device. Additionally, it isn’t clear how, in a multi-vendor supply chain, the submod name is supposed to be unique (not have the same name). This is especially concerning given a module could have multiple instances of the same type of module.

There has been discussion that EAT as a standalone spec can’t reasonably be implemented without a profile. Possibly, the profile context addresses some of these concerns? The PSA draft goes further to define a profile, but I don’t see it directly addressing the consideration for multi-vendor device composition.

The other EAT claims (not submod) seem to imply a simple composition where the thing (module) to which the CWT/JWT is issued / bound is the thing (module) that has the EAT claim.
--snip--