Re: [OPSAWG] Fw: Re: [ntia-sbom-framing] Fwd: 🔔 WG Adoption Call on draft-lear-opsawg-sbom-access-00

[Dick Brooks <[e-mail]>]

Thanks, Henk, you raise a good question. I guess it depends: 

If the goal is to ensure interoperability of SBOM data communicated via an OPSWAG solution, that only exchanges SBOM's then I would imagine that we would need to define which SBOM payloads are supported, to ensure interoperability. If the intent of OPSWAG is to send any type of payload labelled as "SBOM content" with mutually agreed to payloads, then I would agree with you. I view this "tell them what is in the package", very similar to how S/MIME works. For example, when I worked in RFC 1767, EDI over the Internet, we assigned different S/MIME content types for the different type of EDI payloads that could be exchanged (and parsed),  one of the options is "consent". Maybe OPSWAG should include something similar.  

I refer you to this section in the I-D: 

1.2.  SBOM formats

   There are multiple ways to express an SBOM.  When these are retrieved
   either directly from the device or directly from a web server, "tools
   will need to observe the content-type header to determine precisely
   which format is being transmitted".  Because IoT devices in particular
   have limited capabilities, use of a specific Accept: header in HTTP
   or the Accept Option in CoAP is NOT RECOMMENDED.  Instead, backend
   tooling MUST silently discard SBOM information sent with a media type
   that is not understood.


Thanks,

Dick Brooks

Never trust software, always verify and report! ™
http://www.reliableenergyanalytics.com
Email: [e-mail]
Tel: [phone]

-----Original Message-----
From: Henk Birkholz <[e-mail]> 
Sent: Tuesday, January 05, 2021 1:22 PM
To: Dick Brooks <[e-mail]>; 'Christopher Gates' <[e-mail]>; [e-mail]
Cc: Friedman, Allan <[e-mail]>
Subject: Re: [OPSAWG] Fw: Re: [ntia-sbom-framing] Fwd: 🔔 WG Adoption Call on draft-lear-opsawg-sbom-access-00

Hi Dick,

this is Henk with no hats on.

I am not sure how useful it is to make "formats" an exclusive list here. 
Following the evolution of SBOM work in NTIA (and in extension in CISQ), it seems to me that the focus starts to move into the direction of information models first and that actual
format(/serializations/encodings) are starting to be step two.

Certainly, SWID semantics are only in the scope of the artifact domain and don't cover the defects domain and only some of the chains of provenance domain. That is why stand-alone SWID are rather minimal SBOM (just a list of (intended) artifacts).

In any case, I was under the impression that the I-D is format agnostic and that the references are expositional. Is that maybe an underlying point to discuss here?

Viele Grüße,

Henk


On 05.01.21 16:51, Dick Brooks wrote:
> I concur with Chris. I’ve heard reports of people trying to use SWID 
> to communicate SBOM information and they are having to make some “brave”
> assumptions in the process.  SPDX and CycloneDX seem  to be the only 
> viable SBOM formats, based on my testing experience with both formats.
> 
> There remain several issues on naming and identification conventions. 
> A lot of the challenges I’ve experienced could be addressed if NIST 
> NVD and NTIA SBOM parties could reach an agreement on how 
> names/identifiers will be represented in their respective domains. It 
> would only require a few elements to be agreed to, like Publisher 
> name, Product name and Version identifier to make an impactful 
> improvement in vulnerability search results, using SBOM data as inputs.
> 
> Thanks,
> 
> Dick Brooks
> 
> */Never trust software, always verify and report! 
> <https://reliableenergyanalytics.com/products>/* ™
> 
> http://www.reliableenergyanalytics.com
> <http://www.reliableenergyanalytics.com/>
> 
> Email: [e-mail] 
> <mailto:[e-mail]>
> 
> Tel: [phone]
> 
> *From:* OPSAWG <[e-mail]> *On Behalf Of *Christopher 
> Gates
> *Sent:* Tuesday, January 05, 2021 10:27 AM
> *To:* [e-mail]
> *Subject:* [OPSAWG] Fw: Re: [ntia-sbom-framing] Fwd: 🔔 WG Adoption 
> Call on draft-lear-opsawg-sbom-access-00
> 
> ------ Forwarded Message ------
> 
> From: "Christopher Gates" <[e-mail] 
> <mailto:[e-mail]>>
> 
> To: "Eliot Lear" <[e-mail] <mailto:[e-mail]>>; 
> "[e-mail] <mailto:[e-mail]>"
> <[e-mail] <mailto:[e-mail]>>
> 
> Sent: 1/4/2021 2:48:51 PM
> 
> Subject: Re: [ntia-sbom-framing] Fwd: [OPSAWG] 🔔WG Adoption Call on
> draft-lear-opsawg-sbom-access-00
> 
>     Eliot,
> 
>     I joined the IETF WG, and I have some feedback....
> 
>     A "SWID tag" isn't an SBOM format, as stated here. It is an element
>     inside of an SBOM.
> 
>     Since we have removed SWID as a format we in the "NTIA SBOM WG are
>     supporting for SBOM use, shouldn't this reference be removed from
>     the IETF draft as well?
> 
>     Also, I still think that creating a Bluetooth Low Energy SBOM
>     Adopted Profile (via the Bluetooth SIG) that is harmonized with
>     this would be a good thing:
> 
>     Due the the low bandwidth of BLE we wouldn't attempt to provide the
>     SBOM via BLE, just the link to a URI that can deliver the SBOM.
> 
>     It would create a standardized UUID (16 bit) for the SBOM Adopted
>     Profile, and have a consistent set of characteristics being exposed
>     via BLE.
> 
>     This is exactly how an Adopted Profile is supposed to be defined and
>     utilized.
> 
>     Christopher Gates
> 
>     --------------------------------
> 
>     Director of Product Security
> 
>     www.velentium.com <http://www.velentium.com/>
> 
>     [phone]
> 
>     520 Courtney Way Suite 110
> 
>     Lafayette CO. 80026
> 
>     (GMT-7)
> 
>     Our new book is now shipping:
> 
>     /Medical Device Cybersecurity for Engineers and Manufacturers/
> 
>     U.S.
>     <https://us.artechhouse.com/Medical-Device-Cybersecurity-A-Guide-for-Engineers-and-Manufacturers-P2128.aspx> |
>     Worldwide
>     
> <https://uk.artechhouse.com/Medical-Device-Cybersecurity-A-Guide-for-E
> ngineers-and-Manufacturers-P2073.aspx>
> 
>     Amazon
>     <https://www.amazon.com/Medical-Device-Cybersecurity-Engineers-Manufacturers/dp/1630818151/ref=sr_1_1?dchild=1&keywords=Axel+Wirth&qid=1592335625&sr=8-1>&
>     Digital
>     
> <https://us.artechhouse.com/Medical-Device-Cybersecurity-for-Engineers
> -and-Manufacturers-P2174.aspx>
> 
>     Security Book Of The Year!
>     
> <https://engineering.tapad.com/the-best-information-security-books-of-
> 2020-e7430444fbd4>
> 
>     “If everyone is thinking alike, then somebody isn't thinking.”
>     -George S. Patton
> 
>     "Facts are stubborn things."  -John Adams, 1770
> 
>     ------ Original Message ------
> 
>     From: "Eliot Lear via ntia-sbom-framing" <[e-mail]
>     <mailto:[e-mail]>>
> 
>     To: [e-mail] <mailto:[e-mail]>
> 
>     Sent: 1/4/2021 9:57:22 AM
> 
>     Subject: [ntia-sbom-framing] Fwd: [OPSAWG] 🔔WG Adoption Call on
>     draft-lear-opsawg-sbom-access-00
> 
>         FYI- this is your opportunity to contribute to the IETF.  If you
>         think sharing of SBOMs is important, this is a *starting
>         point* for the IETF to begin work on that aspect, not an end
>         point.  Please feel free to contribute by joining the opsawg
>         IETF list at https://www.ietf.org/mailman/listinfo/opsawg.
> 
>         Eliot
> 
> 
> 
>             Begin forwarded message:
> 
>             *From: *Henk Birkholz <[e-mail]
>             <mailto:[e-mail]>>
> 
>             *Subject: [OPSAWG] **🔔**WG Adoption Call on
>             draft-lear-opsawg-sbom-access-00*
> 
>             *Date: *4 January 2021 at 17:10:19 CET
> 
>             *To: *opsawg <[e-mail] <mailto:[e-mail]>>
> 
>             Dear OPSAWG members,
> 
>             this starts a call for Working Group Adoption on
>             https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00
>             ending on Monday, January 25.
> 
>             As a reminder, this I-D describes different ways to acquire
>             Software Bills of Material (SBOM) about distinguishable
>             managed entities. The work was updated by the authors on
>             October 13th and now elaborates on three ways SBOM can be
>             found, including a MUD URI as one of the options.
> 
>             Please reply with your support and especially any
>             substantive comments you may have.
> 
> 
>             For the OPSAWG co-chairs,
> 
>             Henk
> 
>             _______________________________________________
>             OPSAWG mailing list
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/opsawg
> 
> 
> Disclaimer: The information and attachments transmitted by this e-mail 
> are proprietary to Velentium, LLC and the information and attachments 
> may be confidential and legally protected under applicable law and are 
> intended for use only by the individual or entity to whom it was 
> addressed. If you are not the intended recipient, you are hereby 
> notified that any use, forwarding, dissemination, or reproduction of 
> this message and attachments is strictly prohibited and may be unlawful.
> If you are not the intended recipient, please contact the sender by 
> return e-mail and delete this message from your system immediately 
> hereafter.
> 
> 
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg
>