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

2021-01-05 Thread Dick Brooks 
I would support having both SPDX and CycloneDX. Both have proven viable in my 
testing. 

 

Thanks,

 

Dick Brooks



  Never trust software, always 
verify and report! ™

  
http://www.reliableenergyanalytics.com

Email:   
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

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

 

Ok.  Should I add something for CycloneDX?

 

Eliot





On 5 Jan 2021, at 16:51, Dick Brooks mailto:d...@reliableenergyanalytics.com> > 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! ™

  
http://www.reliableenergyanalytics.com

Email:   
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

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

 

 

-- Forwarded Message --

From: "Christopher Gates" mailto:chris.ga...@velentium.com> >

To: "Eliot Lear" mailto:l...@cisco.com> >; 
"ntia-sbom-fram...@cert.org  " 
mailto:ntia-sbom-fram...@cert.org> >

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. 

  | Worldwide 

 

Amazon 

 & Digital 

 

Security Book Of The Year! 

 

 

“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" mailto:ntia-sbom-fram...@cert.org> >

To: ntia-sbom-fram...@cert.org  

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

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

2021-01-05 Thread Dick Brooks 
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

Never trust software, always verify and report! ™
http://www.reliableenergyanalytics.com
Email: d...@reliableenergyanalytics.com
Tel: +1 978-696-1788

-Original Message-
From: Henk Birkholz  
Sent: Tuesday, January 05, 2021 2:20 PM
To: Dick Brooks ; 'Christopher Gates' 
; opsawg@ietf.org
Cc: 'Friedman, Allan' 
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:
> 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: d...@reliableenergyanalytics.com
> Tel: +1 978-696-1788
> 
> -Original Message-
> From: Henk Birkholz 
> Sent: Tuesday, January 05, 2021 1:22 PM
> To: Dick Brooks ; 'Christopher 
> Gates' ; opsawg@ietf.org
> Cc: Friedman, Allan 
> 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!
>> /* ™
>>
>> http://www.reliableenergyanalytics.com
>> 
>>
>> Email: d...@reliableenergyanalytics.com 
>> 
>>

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

2021-01-05 Thread Dick Brooks 
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

Never trust software, always verify and report! ™
http://www.reliableenergyanalytics.com
Email: d...@reliableenergyanalytics.com
Tel: +1 978-696-1788

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

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

Never trust software, always verify and report! ™ 
http://www.reliableenergyanalytics.com
Email: d...@reliableenergyanalytics.com
Tel: +1 978-696-1788

-Original Message-
From: Henk Birkholz 
Sent: Tuesday, January 05, 2021 2:20 PM
To: Dick Brooks ; 'Christopher Gates' 
; opsawg@ietf.org
Cc: 'Friedman, Allan' 
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:
> 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: d...@reliableenergyanalytics.com
> Tel: +1 978-696-1788
> 
> -Original Message-
> From: Henk Birkholz 
> Sent: Tuesday, January 05, 2021 1:22 PM
> To: Dick Brooks ; 'Christopher 
> Gates' ; opsawg@ietf.org
> Cc: Friedman, Allan 
> 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 “