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

[Henk Birkholz <[e-mail]>]

Hi Adrian,

to your first point: I am not sure what legacy systems that would be 
able to create/process EAT would not be able to process a SUIT manifest. 
Could you elaborate on that? I'd maybe not call that a dependency, but 
rather synergy in data models, but I am under the suspicion that I 
simply don't understand the scenario that you are talking about.

To your second point, as the SUIT manifest CDDL specification allows for 
a lot of optional types or members, a small paragraph of which ones to 
use when (like NISTIR 8060 does it for SWID, only on a very much larger 
level) could address that?

Then again, if there is enough interest to do a small subset of new 
firmware related CDDL content as highlighted by Thomas

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

we could add that to the upcoming CoSWID extension. Again, I would like 
to have these additional items as close as possible to the SUIT manifest 
semantically, so there will never be any kind of confusion what each 
value is intended to express and interoperability is "a piece of cake". 
And with respect to firmware semantics, SUIT has the lead here, I think

Viele Grüße,

Henk


On 27.11.19 18:13, Adrian Shaw wrote:
> 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.
>