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

On Wed, Nov 27, 2019 at 12:13 PM Adrian Shaw <Adrian.Shaw@arm.com> 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.
>

Agreed, there are other standards for software update that have been
adopted and use alternate formats for manifests.  I like the idea of
SWID/CoSWID as well.

Best regards,
Kathleen

>
> Adrian
>
> > On 27 Nov 2019, at 16:59, Thomas Fossati <Thomas.Fossati@arm.com> wrote:
> >
> > Hi Henk
> >
> > Thanks very much for your input.
> >
> > On 27/11/2019, 13:24, "Henk Birkholz" <henk.birkholz@sit.fraunhofer.de>
> 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
> > RATS@ietf.org
> > 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.
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>

-- 

Best regards,
Kathleen