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

[Henk Birkholz <[e-mail]>]

Hello Thomas,

we have a coswid extension in the queue that allows for the inclusion of 
hash-entries to very kind of resource-collection type (and also 12-14 
additional indexes, I think, that allow for the creation of Reference 
Integrity Manifests, including hashes for running processes). But this 
will not be submitted this year anymore, I am afraid. Very early next year!

You were not looking at the wrong place, it simply is not there yet, 
because the inclusion of hash-entries is done via "any attributes" in 
ISO XML SWIDs and NISTIR 8060 is focusing on files (not 
filesystem-items, which would include directories).

But we are very aware of that and will remediate that very soon (aka the 
CDDL is already written and passed multi-peer internal review).

It will be less of a "magic firmware recipe", though. If there is 
interest, we can increase the detail about how to reference and locate 
SUIT manifest content (the CDDL unpack operator can help with that, 
therefore retaining the semantic relationship with the SUIT manifest 
however you want to use it).

Viele Grüße,

Henk

On 27.11.19 17:59, Thomas Fossati wrote:
> 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.

Your examples look very close to the CoSWID as RIM, maybe the gaps to 
fill here in order to represent "filesystem-less" firmware is in fact 
relatively small. We will submit the CoSWID RIM part in a few weeks and 
will get some feedback on that (e.g. hash-entries for resources).

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

The SUIT manifest can look very complex (CDDL-wise), but please keep in 
mind that most members (content items) are optional, so an actual 
instance of SUIT manifest can be quite... concise :) While I see the 
point in doing it "all in one thing" the SUIT manifest is an excellent 
representation for what is needed in updating small and big or cloudy 
things and redundant semantics in data formats often create 
corresponding friction in semantic interoperability later on (iotdir hat 
on opinion). So my first reaction is to combine the functionality of 
both and not to recreate the functionality redundantly on each side.

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

Viele Grüße,

Henk