Re: [Rats] Review of draft-ietf-rats-eat-01

[Carl Wallace <[e-mail]>]

> 
> <snip>
>>>> Should 3.11 be 'nested EATs' or 'aggregated EATs'. In other words, are
>>>> these really nested (like signed then encrypted or signed then
>>>> countersigned) or are they aggregated into an array then signed? Should
>>>> these be wrapped as a bstr (at least for CBOR)?
>>> 
>>> They really are nested. It says:
>>> 
>>>    The contents of the "eat" claim must be a fully signed, optionally
>>>    encrypted, EAT token.
>>> 
>>> The nesting is really powerful as it allows multiple subsystems to make EAT
>>> tokens (a modern cell phone has lots of CPUs, often well isolated from each
>>> other) and for them to be combined and bound to each other.
>> 
>> I understand that nesting is powerful and that encryption or other signatures
>> can be applied later. However, the language here reads like aggregation of
>> EATs from various subsystems into a larger composition. Is nesting really
>> what we want there (vs nesting where additional cryptographic services are
>> applied)? Even if nesting is appropriate here, is aggregation something we
>> also want in the toolbox?
> 
> I think we want both aggregation and nesting.
> 
> To be sure it is clear, nesting means you take a fully formed and signed EAT
> token and put it in another fully formed and signed EAT token. One of the
> reasons this might happen is that a device (e.g. a car) is assembled out of
> multiple components that can’t be modified by the end manufacturer.
> Subcomponents are capable of generating EATs. Some final component (controlled
> by the car maker) puts them all together in one token for the car the
> signature of which binds all the sub tokens together.
> 
> The submods claim is the proposed way to do aggregation of claims where the
> subcomponent set of claims is not separately signed.

So that leaves the question of aggregation of signed EATs. There's enough
flexibility that can be added later if it's not viewed as necessary now but
turns out to be useful later. The CMS ContentCollection is what I was
thinking of. 
> 
> <snip>
>