Re: [Rats] [sacm] CoSWID and EAT and CWT

[Thomas Fossati <[e-mail]>]

Hi Henk

Thanks very much for your input.

On 27/11/2019, 13:24, "Henk Birkholz" <[e-mail]> wrote:
> yes there are ways to deal with firmware in SWID, namely the resource
> type (index 19) in the set of SWID resource-collection [1] in
> combination with the rel type (index 40) entries.
>
> This way, you would not have to use filesystem-items, but this way is
> also a bit clunky and would require an informational guidance document
> describing how to use *SWID for that.

That's interesting because initially I also tried to use the resource
type -- which looked like the less wrong among all the available types
in the resource collection.  However it wasn't clear to me how to
associate a checksum to the component, hence I went for the
filesystem-item.  Maybe I was just looking in the wrong place or maybe,
as you say, there's a magic firmware recipe that's worth documenting
here.

> There are some quite smart ways to do that actually with
> filesystem-items, but I think it is more feasible to use a SUIT
> manifest here to describe everything relevant to the "firmware thingy"
> and then put a CoSWID into the SUIT manifest's outer wrapper [2] that
> then represents the rest of the semantics that is not covered by the
> manifest but by CoSWID. This method is fine, as the COSE envelope
> around the EAT will make tempering with the outer wrapper of the SUIT
> Manifest evident.
>
> I think that is a more elegant way to do it, actually, and the reason
> why issue #46 in the EAT repo proposes to define a Claim to include a
> SUIT Manifest in an EAT, too.

I'll look into this, thanks for the pointer.

Stepping back for a second and looking from the perspective of my
immediate requirement (i.e., "Is it possible to translate PSA's software
component claim using purely EAT constructs?"), ideally I'd like to have
something that is expressive enough to encode my semantics (i.e.: SW
component name, version, signer and measurement) without being overly
complex.

So my knee-jerk reaction is if that implies pulling a dependency on
SUIT maybe it's a bit too much?  But I confess haven't yet looked at
the details of your proposal nor I can claim enough SUIT-foo to really
grok the complexity involved.  As said, I'll have a look shortly.

cheers!

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.