Re: [Suit] Parameters and Commands

[Koen Zandberg <[e-mail]>]

Hi Brendan,

On 02/03/2020 16.40, Brendan Moran wrote:
> Hi Koen,
>
> I haven’t heard any complaints about harmonising condition handling to
> parameter-only, so I will take that as a consensus.
No complaints from my side. V4 has this from what I've read in the
changelog.
> <snip>
> This seems quite opaque, so I think using integers would be a better
> choice. This has the advantage that we could cover more policies that
> we haven’t thought of yet without change to the encoding.
I agree with you on this. Using integers here should come for free and
it gives users the option to use (also here) negative numbers for their
custom policies, whatever they might be.
>
> I see what you mean about trading one inconsistency for another. I’m
> not sure if it’s a blocker for this approach or not. If we decide to
> separate reporting policy from SUIT, then there are a few approaches
> we could use to prune the NULLs, but then I’m not sure how to tie RATS
> and SUIT together.

I don't have a better solution at the moment than what you propose here.
Is the full per command granularity required from the RATS side? It is
not sufficient to set a global policy per manifest? And I guess it is
too much overhead to set the policy as a SUIT parameter every time the
policy requires modification during a manifest sequence.

As I mentioned before, I don't consider this a strong concern from my
side and definitely something that can be solved with sufficient
clarification in the spec. From an implementation point of view,
ignoring the nill vs ignoring the integer is trivial.

>
> Effectively my idea is to enable reporting of any measurements that
> are done (conditions). That’s almost enough, however there’s one point
> that is missing from this: Run should be measurable since an argument
> could be passed to Run—c.f. Linux kernel command line, or argc/argv to
> main(). I’ve already floated the idea of making Run imply an image
> condition. This would justify the reporting of a measurement for Run.
> I could see an argument for making the same requirement for Fetch and
> Copy, since they should probably be followed immediately by an image
> condition anyway. All parameters are either invariant or set based on
> conditions, so with a copy of the manifest, you can determine what
> they were.
Looking at the current spec (ietf-v4), I think it is also possible to
move the argument for the fetch and the run directive to a separate
parameter. This way the measurement policy can be included as the
'argument' to the directive. Does this make sense assuming this is the
way measurement settings are included via arguments.
> What would you think of:
>
>  1. All conditions take a measurement policy argument.
>  2. Run implies an image pre-condition before the activation
>  3. Fetch implies an image post-condition
>  4. Copy implies an image post-condition
>  5. Run, Fetch, Copy take a measurement policy argument.
>
Is it the case that we're describing the same idea here? Is this image
pre-condition and post-condition a solution to include a 'measurement'
in these directives?

Cheers,

Koen