The MUD file can certainly point to a single version, but if the MUD file is obtained through some immutable mechanism (device certificate) then the version info has to come from somewhere else.
Eliot > On 29 Apr 2021, at 19:39, Henk Birkholz <henk.birkh...@sit.fraunhofer.de> > wrote: > > Hi Eliot, > > shouldn't be the MUD file (that is maintained by an appropriate authority, > hopefully) in charge of that? The default SBOM retrievable via the MUD file > could therefore always be the latest version? Older versions should be > discoverable via the MUD file or mechanism around that? > > Viele Grüße, > > Henk (no hat) > > On 29.04.21 19:15, Eliot Lear wrote: >> Soo… >> I think this is a bit of an interesting question. If an SBOM lives in the >> cloud somewhere, and it is associated to a version string, how do you know >> which one is the LATEST version? If there is semantic meaning, then the >> inventory management system has to be able to determine that. The simple >> approach would be for the array to be ordered, but I am not a fan of these >> sorts of implicit mechanisms. Another approach would be to index on a date >> rather than a version. >> Eliot >>> On 29 Apr 2021, at 17:16, Dick Brooks <d...@reliableenergyanalytics.com> >>> wrote: >>> >>> Thanks, Eliot. I was just expressing my preferred method of versioning. As >>> long as the spec doesn't disallow semantic versioning, then I'm ok. >>> >>> Thanks, >>> >>> Dick Brooks >>> >>> Never trust software, always verify and report! ™ >>> http://www.reliableenergyanalytics.com >>> Email: d...@reliableenergyanalytics.com >>> Tel: +1 978-696-1788 >>> >>> -----Original Message----- >>> From: Eliot Lear <l...@cisco.com> >>> Sent: Thursday, April 29, 2021 10:25 AM >>> To: Dick Brooks <d...@reliableenergyanalytics.com> >>> Cc: Eliot Lear <lear=40cisco....@dmarc.ietf.org>; opsawg <opsawg@ietf.org> >>> Subject: Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access >>> >>> Hi Dick >>> >>> When you say semantic versioning, what do you have in mind? Keep in mind >>> that we want to be neutral to format. >>> >>> Eliot >>> >>>> On 29 Apr 2021, at 15:30, Dick Brooks <d...@reliableenergyanalytics.com> >>>> wrote: >>>> >>>> Eliot, >>>> >>>> Here is the information I use in SAG-PM to discover and retrieve an SBOM; >>>> hope this helps. Version is a must have attribute of the product >>>> definition to retrieve the correct SBOM. >>>> >>>> Semantic versioning is preferred: MAJOR.MINOR.PATCH >>>> >>>> <Product> >>>> <LicensorName>Reliable Energy Analytics LLC</LicensorName> >>>> <ProductName>SAG-PM (TM)</ProductName> >>>> <Version>1.1.0</Version> >>>> <SBOM type="cyclone" version="1.2" format="XML" >>>> signature="https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml.sig";>https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml</SBOM> >>>> >>>> <SourceLocationURL>https://softwareassuranceguardian.com/sag-pm.zip</SourceLocationURL> >>>> <DigitallySigned>Y</DigitallySigned> >>>> <UnsolvedVulnerabilities>N</UnsolvedVulnerabilities> >>>> >>>> <LastModifiedDateTimeUTC>2021-04-23T15:57:00</LastModifiedDateTimeUTC> >>>> </Product> >>>> >>>> >>>> Thanks, >>>> >>>> Dick Brooks >>>> >>>> Never trust software, always verify and report! ™ >>>> http://www.reliableenergyanalytics.com >>>> Email: d...@reliableenergyanalytics.com >>>> Tel: +1 978-696-1788 >>>> >>>> -----Original Message----- >>>> From: OPSAWG <opsawg-boun...@ietf.org> On Behalf Of Eliot Lear >>>> Sent: Thursday, April 29, 2021 9:15 AM >>>> To: opsawg <opsawg@ietf.org> >>>> Subject: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access >>>> >>>> The current draft allows for multiple SBOM versions. The reason for this >>>> is that if a MUD URL is used, and the SBOM is contained on a server >>>> somewhere, one would need to use out of band information to determine >>>> software versions. However, this doesn’t make sense if you are retrieving >>>> the SBOM from the device. Therefore, the model needs to change a bit. >>>> >>>> We want a “when” clause somewhere for the version info, but this >>>> introduces an new challenge: as currently listed the version-info field is >>>> an index. That has to go. >>>> >>>> So… what I think we want to do is invert the list along the following >>>> lines: >>>> >>>> - choice sbom-type: >>>> case url: >>>> list sboms >>>> leaf version-info >>>> leaf sbom-url >>>> case local-uri: >>>> type empty - the whole thing is constructed using >>>> .well-known/sbom >>>> case contact-info: as before but without versioning >>>> >>>> >>>> Anyway, this is what I am thinking. Thoughts? >>>> >>>> Eliot >>>> >>>> _______________________________________________ >>>> OPSAWG mailing list >>>> OPSAWG@ietf.org >>>> https://www.ietf.org/mailman/listinfo/opsawg >>> >>> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
