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

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

Right now the scope of RATS focuses on Attester to Verifier and Verifier to Relying Party flows. Flows from Asserter (supply chain entity) to Verifier are out of scope currently. The use cases for counter signing and multiple signing may relate more to supply chain than Attester to Verifier.

Aggregation (if I’m not mistaken) is when a Verifier communicates to a Relying Party. A simple aggregation might be to “allow” or “deny” (or maybe I’m misunderstanding what is meant by aggregation).

On 7/16/19, 2:23 PM, "RATS on behalf of Carl Wallace" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:


<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>