Subject: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access

From: Eliot Lear <[email-masked]>
Date: Thu, 29 Apr 2021 15:15:00 +0200

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

---

From: "Dick Brooks" <[email-masked]>
Date: Thu, 29 Apr 2021 09:30:40 -0400

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: [email-masked]
Tel: +1 978-696-1788

-----Original Message-----
From: OPSAWG <[email-masked]> On Behalf Of Eliot Lear
Sent: Thursday, April 29, 2021 9:15 AM
To: opsawg <[email-masked]>
Subject: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access

 - choice sbom-type:
	case url:
		list sboms
			leaf version-info
			leaf sbom-url
	case local-uri:

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Thu, 29 Apr 2021 16:24:54 +0200

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 <[email-masked]> wrote:
> 
> Eliot,
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Dick Brooks" <[email-masked]>
Date: Thu, 29 Apr 2021 11:16:08 -0400

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

-----Original Message-----
From: Eliot Lear <[email-masked]> 
Sent: Thursday, April 29, 2021 10:25 AM
To: Dick Brooks <[email-masked]>
Cc: Eliot Lear <lear=[email-masked]>; opsawg <[email-masked]>
Subject: Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access

Hi Dick

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Thu, 29 Apr 2021 19:15:30 +0200

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 <[email-masked]> wrote:
>

---

From: "Dick Brooks" <[email-masked]>
Date: Thu, 29 Apr 2021 13:26:11 -0400

Here's how it works with SAG-PM:

1. Customer downloads a software object to be installed.
2. SAG-PM introspects the downloaded file for identification properties:

Performing program introspection; storing SBOM information for posterity
*************** PROPERTIES *******************
----> Manufacturer : Reliable Energy Analytics LLC
----> ProductCode : {C0AF4A54-0C0A-4948-BF1F-A66089EF4C5A}
----> ProductName : SAG-PM (TM)
----> ProductVersion : 1.1.0
NOTE: A username and password are required to access this Questionnaire
---->Enter Username for Vendor Reliable Energy Analytics LLC :

3. This information is used to lookup the vendor, product and version in a local database, which identifies the "VendorResponse" data (see attached example)
4. Retrieve the Vendor response data, then download the SBOM identified for that Vendor/Product/Version
5 Perform the remaining risk assessment steps.

Thanks,

Dick Brooks

-----Original Message-----
From: Eliot Lear <[email-masked]> 
Sent: Thursday, April 29, 2021 1:16 PM
To: [email-masked]
Cc: Eliot Lear <lear=[email-masked]>; opsawg <[email-masked]>
Subject: Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access

Soo…

Eliot

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 29 Apr 2021 19:39:47 +0200

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)

---

From: Eliot Lear <[email-masked]>
Date: Thu, 29 Apr 2021 19:42:48 +0200

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 <[email-masked]> 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)
>

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 29 Apr 2021 19:46:08 +0200

I was under the assumption that the thing that is immutable is the MUD 
URL right (e.g. if it resides in an IDevID)? Is a specific MUD URL 
statically linked to one specific MUD file? If not, you could update the 
MUD file to always point to the latest version (first, other linked via 
that MUD file maybe) - or would that defeat some purpose that I am 
missing or forgot?

---

From: Eliot Lear <[email-masked]>
Date: Thu, 29 Apr 2021 19:49:11 +0200

> On 29 Apr 2021, at 19:46, Henk Birkholz <[email-masked]> wrote:
> 
> I was under the assumption that the thing that is immutable is the MUD URL right

Yes, if it is in the certificate.  So now you go to the MUD file.  Surely that can be updated with new version information.  But if devices still have the old version, you have to handle that as well.

This is an area which eventually can be helped by RATS, if one of the attestation information elements is version information.

Eliot

---

From: Patrick Dwyer <[email-masked]>
Date: Fri, 30 Apr 2021 11:04:53 +1000

When you say multiple SBOM versions, do you mean multiple versions of SBOMs
that describe the same particular version of software? Or multiple SBOMs
for different versions of the same software?

On Thu, Apr 29, 2021 at 11:15 PM Eliot Lear <lear=[email-masked]>
wrote:

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

---

From: "Panwei (William)" <[email-masked]>
Date: Fri, 30 Apr 2021 02:40:18 +0000

Hi Henk,

> If not, you could update the MUD file to
> always point to the latest version

If you do so, then the MUD file only adapts to the devices which use the latest version. Actually, you can't guarantee all devices been updated at the same time, so the devices which haven't been updated will be pointed out to the wrong MUD file.
draft-ietf-opsawg-mud-acceptable-urls tries to solve this problem by update the MUD URL in some secure ways.

Regards & Thanks!
Wei Pan

> From: OPSAWG [mailto:[email-masked]] On Behalf Of Henk
> Birkholz
> Sent: Friday, April 30, 2021 1:46 AM
> To: Eliot Lear <[email-masked]>
> Cc: opsawg <[email-masked]>
> URL right (e.g. if it resides in an IDevID)? Is a specific MUD URL statically
> linked to one specific MUD file? If not, you could update the MUD file to
> always point to the latest version (first, other linked via that MUD file maybe)
> - or would that defeat some purpose that I am missing or forgot?
> 
> > 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
> >
> 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)
> >>
> >>> 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
> <[email-masked]> 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
> >>>>
> >>>> 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
> <[email-masked]> 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.
> >>>>>
> >>>>>            <SBOM type="cyclone" version="1.2" format="XML"
> signature="https://softwareassuranceguardian.com/SAG-PM-cycloneDX.x
> ml.sig">https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml<
> /SBOM>
> >>>>>
> >>>>> 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
> introduces an new challenge: as currently listed the version-info field is an
> index.  That has to go.
> >>>>>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 30 Apr 2021 20:53:04 +0200

Hi Patrick

> On 30 Apr 2021, at 03:04, Patrick Dwyer <[email-masked]> wrote:
> 
> When you say multiple SBOM versions, do you mean multiple versions of SBOMs that describe the same particular version of software? Or multiple SBOMs for different versions of the same software?

Different versions.

Eliot