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

[Thomas Fossati <[e-mail]>]

hi Laurence,

I agree with you that submods exist for a very good reason. They have
particular value if the composition pattern is static and known
a-priori (Ned's email has some interesting points in this regard). The
existence of submods has enabled some interesting expression during
prototyping efforts here.  Note also that I would be concerned
that if submods did not exist then that might result in multiple custom
solutions emerging to express nesting, which would be a poor result for
the wider RATS standardisation efforts.

The current definition is nice and simple, though I would like to
explore some extra functionality at some point. The small trouble I have
with it is that the string type limits the expressiveness of the submod
identifier.  Ideally, one could have a composite, more powerful type on
the LHS of the submod definition.  Note that this would be possible in
CBOR but not in JSON, so if we want interworking between the two formats
we'd need to find another solution. For example one where the RHS
clearly separates identification information from the measurements.  At
that point the string key would be redundant, or left as a hint.  At the
moment I don't have a very concrete proposal (i.e., code) though, so
this is just a thought.

cheers,





On Wed, Dec 15, 2021 at 7:01 PM Laurence Lundblade
<[e-mail]> wrote:
>
> Lots discussion on EAT. :-)
>
> Chunking through it...
>
> On Dec 9, 2021, at 2:45 AM, Hannes Tschofenig <[e-mail]> wrote:
>
> Laurence wrote:
>
> There’s strong logic here:
> — RATS architecture explicitly calls out composite attestation — A submodule can be a nested EAT to implement composite attestation — A nested EAT can be a CWT, UCCS  or DEB — The CDDL that specifies a nested EAT submodule thus must mention UCCS
>
> So a UCCS is a claim that goes into a CWT. I think UCCS, particularly CDDL for UCCS, must be included because of this.
>
>
> [Hannes] I wonder whether everything in the RATS architecture should be covered in the EAT specification for several reasons:
> - First, the EAT spec becomes complex and harder to read.
> - Second, the RATS architecture enumerates everything that came into someone's mind or, as we later learned, can be patented.
> - Given the status of the industry with attestation I believe it will take a while to even get the basic functionality deployed. For more complex use cases it can easily take several years.
>
>
> In the above, I said that RATS architecture has composite attestation and therefor we need EAT submods. Hannes is maybe suggesting we don’t need submods because they add too much complexity.
>
> 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.
>
> - submods give EAT a very substantial expressive power for all sorts of use cases. Not having them would result in people inventing ad hoc schemes for their use cases.
>
>
> - I recall a few conversations with various folks that see important for submods in their use cases
>
>
> I have a strong conviction that submods, including nested tokens, are necessary for EAT now and are worth the complexity they add.
>
> LL
>
> (Happy to consider improvements to the submods design)
> (Submods != UCCS/UJCS; UCCS and UJCS are related, but can be a separate decision)
>
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats



--
Thomas