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

[Adrian Shaw <[e-mail]>]

While there is some synergy with the SUIT definition, I’m unconvinced that it should be the way to express a software component metadata. Firstly, there are legacy systems without SUIT that would want to use EAT, and such a dependency would make it hard for incremental adoption. Secondly, not all the data from the SUIT manifest is needed for this claim.

Adrian

> On 27 Nov 2019, at 16:59, Thomas Fossati <[e-mail]> 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.
>
> 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.
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats

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.