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

From: "Christopher Gates" <[email-masked]>
Date: Tue, 05 Jan 2021 15:26:48 +0000

------ Forwarded Message ------
From: "Christopher Gates" <[email-masked]>
To: "Eliot Lear" <[email-masked]>; "[email-masked]" 
<[email-masked]>
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
>
>(805)750-0171
>
>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-Engineers-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" <[email-masked]>
>To: [email-masked]
>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 <[email-masked]>
>>>Subject: [OPSAWG] 🔔 WG Adoption Call on 
>>>draft-lear-opsawg-sbom-access-00
>>>Date: 4 January 2021 at 17:10:19 CET
>>>To: opsawg <[email-masked]>
>>>
>>>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
>>>[email-masked]
>>>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.

---

From: "Dick Brooks" <[email-masked]>
Date: Tue, 5 Jan 2021 10:51:56 -0500

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

 <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™

 <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com

Email:  <mailto:[email-masked]> [email-masked]

Tel: +1 978-696-1788

From: OPSAWG <[email-masked]> On Behalf Of Christopher Gates
Sent: Tuesday, January 05, 2021 10:27 AM
To: [email-masked]
Subject: [OPSAWG] Fw: Re: [ntia-sbom-framing] Fwd: 🔔 WG Adoption Call on draft-lear-opsawg-sbom-access-00

------ Forwarded Message ------

From: "Christopher Gates" <[email-masked] <mailto:[email-masked]> >

To: "Eliot Lear" <[email-masked] <mailto:[email-masked]> >; "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >

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

Eliot,

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

www.velentium.com <http://www.velentium.com/> 

(805)750-0171

Lafayette CO. 80026

(GMT-7)

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

------ Original Message ------

From: "Eliot Lear via ntia-sbom-framing" <[email-masked] <mailto:[email-masked]> >

To: [email-masked] <mailto:[email-masked]> 

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

Subject: [OPSAWG] 🔔 WG Adoption Call on draft-lear-opsawg-sbom-access-00

To: opsawg <[email-masked] <mailto:[email-masked]> >

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.

Henk

_______________________________________________
OPSAWG mailing list
[email-masked] <mailto:[email-masked]> 
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.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 5 Jan 2021 16:53:17 +0100

Ok.  Should I add something for CycloneDX?

Eliot

> On 5 Jan 2021, at 16:51, Dick Brooks <[email-masked]> wrote:
> 
> Never trust software, always verify and report! <https://reliableenergyanalytics.com/products> ™
> http://www.reliableenergyanalytics.com <http://www.reliableenergyanalytics.com/>
> Email: [email-masked] <mailto:[email-masked]>
> Tel: +1 978-696-1788
> 
> From: OPSAWG <[email-masked] <mailto:[email-masked]>> On Behalf Of Christopher Gates
> To: [email-masked] <mailto:[email-masked]>
> From: "Christopher Gates" <[email-masked] <mailto:[email-masked]>>
> To: "Eliot Lear" <[email-masked] <mailto:[email-masked]>>; "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> 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>
>> From: "Eliot Lear via ntia-sbom-framing" <[email-masked] <mailto:[email-masked]>>
>>> 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 <https://www.ietf.org/mailman/listinfo/opsawg>.
>>> 
>>> Eliot
>>> 
>>> 
>>>> Begin forwarded message:
>>>> 
>>>> From: Henk Birkholz <[email-masked] <mailto:[email-masked]>>
>>>> To: opsawg <[email-masked] <mailto:[email-masked]>>
>>>> 
>>>> Dear OPSAWG members,
>>>> 
>>>> this starts a call for Working Group Adoption on https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00 <https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00> ending on Monday, January 25.
>>>> 
>>>> https://www.ietf.org/mailman/listinfo/opsawg <https://www.ietf.org/mailman/listinfo/opsawg>
>>> 
> 
> 
> https://www.ietf.org/mailman/listinfo/opsawg <https://www.ietf.org/mailman/listinfo/opsawg>

---

From: "Dick Brooks" <[email-masked]>
Date: Tue, 5 Jan 2021 10:55:32 -0500

I would support having both SPDX and CycloneDX. Both have proven viable in my testing. 

Thanks,

Dick Brooks

Tel: +1 978-696-1788

From: Eliot Lear <[email-masked]> 
Sent: Tuesday, January 05, 2021 10:53 AM
To: Dick Brooks <[email-masked]>
Cc: Christopher Gates <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [OPSAWG] Fw: Re: [ntia-sbom-framing] Fwd: 🔔 WG Adoption Call on draft-lear-opsawg-sbom-access-00

Eliot

On 5 Jan 2021, at 16:51, Dick Brooks <[email-masked] <mailto:[email-masked]> > wrote:

Thanks,

Dick Brooks

Tel: +1 978-696-1788

From: OPSAWG <[email-masked] <mailto:[email-masked]> > On Behalf Of Christopher Gates
Sent: Tuesday, January 05, 2021 10:27 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: [OPSAWG] Fw: Re: [ntia-sbom-framing] Fwd: 🔔 WG Adoption Call on draft-lear-opsawg-sbom-access-00

------ Forwarded Message ------

Eliot,

 

 

 

Christopher Gates

(805)750-0171

Lafayette CO. 80026

(GMT-7)

------ Original Message ------

Eliot

Begin forwarded message:

Dear OPSAWG members,

Henk

_______________________________________________
OPSAWG mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/opsawg> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Eliot Lear <[email-masked]>
Date: Tue, 5 Jan 2021 17:12:43 +0100

Thanks, Tony.

What we’ll to make clear is how to know what to retrieve.  HTTP has a pretty good interface for that with media types, and you can match that with an Accepts: header, if one really wants to (my guess is that the tooling will want to take on the burden of implementing both, and the suppliers will just provide what they have, at least for a while.

Eliot

> On 5 Jan 2021, at 17:01, Tony Turner <[email-masked]> wrote:
> 
> I think you have to support both and have ability to map between the two if you want to have any hope of interoperability because the standards universe here is very fragmented. I see more appsec products supporting CycloneDX while I see more software providers supporting SPDX. And then multiple other providers doing their own proprietary thing, either a variation of SPDX or something entirely new. Some SBOMs I see are nothing more than a software (not component) inventory as discovered on disk, or just a basic table with supplier, component, version.
> 
> On Tue, Jan 5, 2021 at 10:56 AM Dick Brooks <[email-masked] <mailto:[email-masked]>> wrote:
> From: Eliot Lear <[email-masked] <mailto:[email-masked]>>
> To: Dick Brooks <[email-masked] <mailto:[email-masked]>>
> Cc: Christopher Gates <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On 5 Jan 2021, at 16:51, Dick Brooks <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
> Tony Turner
> VP, Security Solutions
> Fortress Information Security
> Cell  321-634-4886 Main 855.FORTRESS
> 189 S. Orange Ave., Suite 1950, Orlando, FL 32801
> fortressinfosec.com <http://fortressinfosec.com/>
> CONFIDENTIAL:
> 
> The information transmitted is intended only for the person or entity to which it is addressed. The content may contain confidential and/or privileged material, and it may be reviewed and logged for archival purposes by parties at Fortress Information Security other than those named in the message header. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 5 Jan 2021 19:21:56 +0100

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: [email-masked] 
> <mailto:[email-masked]>
> 
> Tel: +1 978-696-1788
> 
> *From:* OPSAWG <[email-masked]> *On Behalf Of *Christopher Gates
> *Sent:* Tuesday, January 05, 2021 10:27 AM
> *To:* [email-masked]
> *Subject:* [OPSAWG] Fw: Re: [ntia-sbom-framing] Fwd: 🔔 WG Adoption Call 
> on draft-lear-opsawg-sbom-access-00
> 
> To: "Eliot Lear" <[email-masked] <mailto:[email-masked]>>; 
> "[email-masked] <mailto:[email-masked]>" 
> <[email-masked] <mailto:[email-masked]>>
> 
> Subject: Re: [ntia-sbom-framing] Fwd: [OPSAWG] 🔔WG Adoption Call on 
>     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:
> 
>     Profile, and have a consistent set of characteristics being exposed
>     via BLE.
> 
>     /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://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
>     Subject: [ntia-sbom-framing] Fwd: [OPSAWG] 🔔WG Adoption Call on
>         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 <[email-masked]
>             <mailto:[email-masked]>>
> 
>             *Subject: [OPSAWG] **🔔**WG Adoption Call on
>             draft-lear-opsawg-sbom-access-00*
> 
>             *Date: *4 January 2021 at 17:10:19 CET
> 
>             *To: *opsawg <[email-masked] <mailto:[email-masked]>>
> 
>             Dear OPSAWG members,
> 
>             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.
> 
> 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.
> 
>

---

From: "Dick Brooks" <[email-masked]>
Date: Tue, 5 Jan 2021 14:04:17 -0500

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

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

Hi Dick,

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”
> 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
> 
> *Subject:* [OPSAWG] Fw: Re: [ntia-sbom-framing] Fwd: 🔔 WG Adoption 
> Call on draft-lear-opsawg-sbom-access-00
>

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 5 Jan 2021 20:20:09 +0100

Hi Dick,

exactly. Now it seems to me, there might be some dependencies on "sbom 
type definitions" here.

What now springs to my mind are the questions: If there are media-types 
or corresponding content-formats required to be expressed in headers in 
order to make this work, (1) where are these specified and (2) where are 
these expected be registered?

Viele Grüße,

Henk

---

From: "Dick Brooks" <[email-masked]>
Date: Tue, 5 Jan 2021 14:56:21 -0500

I agree, Henk. I don't know if there are registered MIME content types for spdx and cycloneDX. With RFC 1767, Dave Crocker took care of registering the EDI MIME content types. 

Thanks,

Dick Brooks

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

Hi Dick,

exactly. Now it seems to me, there might be some dependencies on "sbom type definitions" here.

What now springs to my mind are the questions: If there are media-types or corresponding content-formats required to be expressed in headers in order to make this work, (1) where are these specified and (2) where are these expected be registered?

Viele Grüße,

Henk

On 05.01.21 20:04, Dick Brooks wrote:
> To: Dick Brooks <[email-masked]>; 'Christopher 
> Gates' <[email-masked]>; [email-masked]
> 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
>> <https://uk.artechhouse.com/Medical-Device-Cybersecurity-A-Guide-for-
>> E ngineers-and-Manufacturers-P2073.aspx>
>>
>>      Amazon
>> <https://us.artechhouse.com/Medical-Device-Cybersecurity-for-Engineer
>> s
>> -and-Manufacturers-P2174.aspx>
>>
>> <https://engineering.tapad.com/the-best-information-security-books-of
>> -
>> 2020-e7430444fbd4>
>>
>> <mailto:[email-masked]>
>>
>> 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.

---

From: "Dick Brooks" <[email-masked]>
Date: Tue, 5 Jan 2021 15:05:19 -0500

Spdx has a registered MIME type, but CycloneDX doesn't appear to have one.

https://www.iana.org/assignments/media-types/text/spdx

Thanks,

Dick Brooks

-----Original Message-----
From: OPSAWG <[email-masked]> On Behalf Of Dick Brooks
Sent: Tuesday, January 05, 2021 2:56 PM
To: 'Henk Birkholz' <[email-masked]>; 'Christopher Gates' <[email-masked]>; [email-masked]
Cc: 'Friedman, Allan' <[email-masked]>
Subject: Re: [OPSAWG] Fw: Re: [ntia-sbom-framing] Fwd: ?? WG Adoption Call on draft-lear-opsawg-sbom-access-00

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: Henk Birkholz <[email-masked]>
Sent: Tuesday, January 05, 2021 2:20 PM
To: Dick Brooks <[email-masked]>; 'Christopher Gates' <[email-masked]>; [email-masked]
Cc: 'Friedman, Allan' <[email-masked]>
Subject: Re: [OPSAWG] Fw: Re: [ntia-sbom-framing] Fwd: 🔔 WG Adoption Call on draft-lear-opsawg-sbom-access-00

Hi Dick,

Viele Grüße,

Henk

---

From: Tony Turner <[email-masked]>
Date: Tue, 5 Jan 2021 11:01:34 -0500

I think you have to support both and have ability to map between the two if
you want to have any hope of interoperability because the standards
universe here is very fragmented. I see more appsec products supporting
CycloneDX while I see more software providers supporting SPDX. And then
multiple other providers doing their own proprietary thing, either a
variation of SPDX or something entirely new. Some SBOMs I see are nothing
more than a software (not component) inventory as discovered on disk, or
just a basic table with supplier, component, version.

On Tue, Jan 5, 2021 at 10:56 AM Dick Brooks <
[email-masked]> wrote:

> *Never trust software, always verify and report!
> <https://reliableenergyanalytics.com/products>* ™
>
> *From:* Eliot Lear <[email-masked]>
> *Sent:* Tuesday, January 05, 2021 10:53 AM
> *To:* Dick Brooks <[email-masked]>
> *Cc:* Christopher Gates <[email-masked]>; [email-masked];
> [email-masked]
> *Subject:* Re: [OPSAWG] Fw: Re: [ntia-sbom-framing] Fwd: 🔔 WG Adoption
> assumptions in the process.  SPDX and CycloneDX seem  to be the only viable
> SBOM formats, based on my testing experience with both formats.
>
>
>
> 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>* ™
>
> To: "Eliot Lear" <[email-masked]>; "[email-masked]" <
> [email-masked]>
>
> supporting for SBOM use, shouldn't this reference be removed from the IETF
> draft as well?
>
>
>
>
>
> 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.
>
> *Medical Device Cybersecurity for Engineers and Manufacturers*
>
> U.S.
> 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
> *From: *Henk Birkholz <[email-masked]>
>
> *Subject: [OPSAWG] **🔔* *WG Adoption Call on
> *To: *opsawg <[email-masked]>
>
>
>
> Dear OPSAWG members,
>
> 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.
>

-- 
*Tony Turner*
VP, Security Solutions
*Fortress Information Security*
*Cell * 321-634-4886 *Main* 855.FORTRESS
189 S. Orange Ave., Suite 1950, Orlando, FL 32801
*fortressinfosec.com <http://fortressinfosec.com/>*

-- 
_CONFIDENTIAL: 

The information transmitted is intended only for the 
person or entity to which it is addressed. The content may contain 
confidential and/or privileged material, and it may be reviewed and logged 
for archival purposes by parties at Fortress Information Security other 
than those named in the message header. Any views or opinions presented in 
this email are solely those of the author and do not necessarily represent 
those of the company. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon this information by 
persons or entities other than the intended recipient is prohibited. If you 
received this in error, please contact the sender and delete the material 
from any computer._