RE: EXT :[openc2] RE: EXT :[openc2] RE: Updates to SBOM sharing draft

Eliot,

 

One update: there’s now a PR to address the HTTP
endpoint path ambiguity issue: 
https://github.com/oasis-tcs/openc2-impl-https/pull/114

 

It specifies “/openc2/” as the path portion of the URI.  There wasn’t much support in the TC working meeting discussions or our on-line issue discussion to use the “/.well-known/” mechanism.

 

Dave

 

David Lemire

IA Systems Engineer

Technical Solutions

302 Sentinel Drive | Annapolis Junction, MD 20701

Work (301) 575-5190 |
Mobile (240) 938-9350

 

From:  [mailto:]
On Behalf Of Lemire, Dave (HII-TSD)

Sent: Wednesday, July 14, 2021 2:26 PM

To: ; Eliot Lear <>; duncan sfractal.com <>

Cc: TC OpenC2 () <>

Subject: EXT :[openc2] RE: EXT :[openc2] RE: Updates to SBOM sharing draft

 

CAUTION: This email originated from outside your organization. Exercise caution when opening attachments or clicking links, especially from unknown senders.

 

We do have a repository for an SBOM AP, but unfortunately the editor has had higher priorities so it lacks any recent updates.  However, if you

pick up reading here [github.com] in the editor’s fork, you can get an impression of at least the initial approach being suggested (no point in reading beyond the end of section 2 right now [i.e., through 2.3.3.1]).

 

A work item for the 
HTTPS Transfer Spec [github.com]  (link to working version on GH) is to standardize on the path; there an

open issue [github.com] on GitHub for that. I’d been thinking that we would simply use
/openc2 for the path. I hadn’t consider the use of the
.well-known approach (something I’d only learned of recently) but there’s no reason we couldn’t go that route instead.

 

Regarding MQTT, our 
transfer spec for that [github.com] is nearly ready to go to public review. The default topic structure for sending commands is documented in

section 2.2 [github.com]; for this purpose the topic would be oc2/cmd/ap/sbom (+/- some other considerations) to listen for SBOM retrieval commands.

 

Dave

 

David Lemire

IA Systems Engineer

Technical Solutions

302 Sentinel Drive | Annapolis Junction, MD 20701

Work (301) 575-5190 |
Mobile (240) 938-9350

 

From:  [mailto:]
On Behalf Of 

Sent: Wednesday, July 14, 2021 1:36 PM

To: Eliot Lear <>; duncan sfractal.com <>

Cc: TC OpenC2 () <>

Subject: EXT :[openc2] RE: Updates to SBOM sharing draft

 

CAUTION: This email originated from outside your organization. Exercise caution when opening attachments or clicking links, especially from unknown senders.

 

The OpenC2 HTTPS Transfer Specification 
https://github.com/oasis-tcs/openc2-impl-https/blob/working/open-impl-https.md shows an example OpenC2 [github.com] message in Annex B:

POST /openc2 HTTP/1.1

Content-type: application/openc2+json;version=1.0

Date: Wed, 19 Dec 2018 22:15:00 GMT

X-Request-ID: d1ac0489-ed51-4345-9175-f3078f30afe5

 

{

  "headers": {

    "request_id": "d1ac0489-ed51-4345-9175-f3078f30afe5"

    "created": 1545257700000,

    "from": "oc2producer.company.net",

    "to": ["oc2consumer.company.net"]

  },

  "body": {

    "openc2": {

      "request": {

        "action": ...

        "target": ...

        "args": ...

      }

    }

  }

}

The OpenC2 Language Specification 
https://github.com/oasis-tcs/openc2-oc2ls/blob/working/oc2ls.md section 3.3.1 [github.com] defines the value of the “request” property – an OpenC2-Command, and the possible values for “action”.  Fetching an SBOM would use the “query” action (“initiate a
 request for information”).  The target field of the query and the response format would be defined in an SBOM actuator profile document, not yet written, but the target would identify the particular SBOM to receive and the desired formats.  The response would
 be one or more SBOMs in the requested format(s), either as blobs uninterpreted by OpenC2 or as information objects translated to the serialization used by OpenC2.  (For example if the SBOM were in SPDX tag-value format, the device could send it as-is text
 or convert it to JSON in the SPDX JSON format.  Presumably IoT devices would send blobs.  More capable services could do the reserialization.)

After writing that I realize that OpenC2 is not very reader-friendly – just to get started you need to read the language spec, a transfer spec, and an SBOM profile.  We are chartered to keep it modular, but there is a barrier to entry by doing so.   Our future
 work is to write the SBOM profile with complete examples that could be the single document you could reference.

Dave

 

From: Eliot Lear <>

Sent: Friday, July 9, 2021 9:20 AM

To: duncan sfractal.com <>

Cc: TC OpenC2 () <>; Dave Kemp (GOV) <>

Subject: Re: Updates to SBOM sharing draft

 

This deserves elaboration:

 

There are three mentions of OpenC2 in draft-ietf-opsawg-sbom-access.  Two involve modes that would be listed in the discovery mechanism for SBOMs and VEXes (CSAF files) respectively.  The 3rd is the use of .well-known.  I can happily try
 to register such an endpoint for OpenC2 in this draft.  The value is simply that people can go to

https://{host}/.well-known/openc2 [%7bhost%7d] and make use of the HTTP binding.  That’s not a problem.  What’s more of a problem is that I don’t really know where to point people in the OpenC2 spec to retrieve an SBOM or a VEX.

 

In addition, if you want the MQTT binding in, after some thought, I think we can do that, but I need to make some model changes.  Specifically, there need to be enough parameters passed so that the network management system can subscribe
 to the correct topic (I think).  I’m not an MQTT expert, but this doesn’t seem impossible.

 

If you like, I can meet with the team during the 1st week of August, and I will be happy to code up any changes both in the draft and in the generation tool.  All changes to the draft are subject to IETF working group consensus, but so
 long as we’re doing our level best to keep it secure, nobody’s going to jump up and down (I don’t think).

 

Eliot

 

On 9 Jul 2021, at 15:05, duncan 
sfractal.com [gcc02.safelinks.protection.outlook.com] <> wrote:

 

IETF has an RFC that references using OpenC2. Attached is some work circulated to the SBOM crowd. 

 

According to IETF gurus we need to :

“OpenC2 needs to catch up to this work if they want to remain after WGLC (them’s the rules).  I’ve reinitiated a discussion with those guys.”

I’m not sure what the means but we should do it promptly.

Dave K (or L or anyone else) I’d appreciate help in doing this. 

 

iPhone, iTypo, iApologize

Duncan

 

From: 
ntia-sbom-framing-bounces+duncan= <ntia-sbom-framing-bounces+duncan=> on behalf of Eliot Lear via ntia-sbom-framing <>

Sent: Friday, July 9, 2021 8:06 AM

To: ntia-sbom-framing

Cc: Rose, Scott W.

Subject: Re: [ntia-sbom-framing] Updates to SBOM sharing draft 

 

This time with the draft attached. 

 

 

On 9 Jul 2021, at 13:57, Eliot Lear <> wrote:

 

Hi everyone, 

 

As discussed, Scott and I have updated the SBOM sharing draft.  As agreed, it handles VEX and SBOMs independently.  We need to get this posted by Monday for the draft deadline.  A few of the more salient points:

 

The intro is rewritten a bit to make clear what the key questions are.  We don’t focus on licensing in this draft, though there is one sentence about them in formats and format neutrality.

There are two independent “choices” in terms of how the information is retrieved- one for SBOMs and one for VEXes.  Each are roughly speaking the same.

Each maintains format neutrality.  There is also some text in there about what if the VEX and the SBOM file are the same.  That’s to address (obliquely) CycloneDX.

We managed to write the entire draft without using the term “VEX”.

OpenC2 needs to catch up to this work if they want to remain after WGLC (them’s the rules).  I’ve reinitiated a discussion with those guys.

We’ve taken Pat’s feedback to create separate well-known suffixes rather than to establish a tree.

I’ve updated 
https://mudmaker.org/test [gcc02.safelinks.protection.outlook.com] with a version that does All Of This.

 

One question is just whether it should ever be expected that vulnerability information be kept on the box.  That seems like a stretch, even though the draft supports it.

 

Please see attached, and you can view the source at https://github.com/elear/mud-sbom/tree/vex
 [gcc02.safelinks.protection.outlook.com].  This will probably get merged over the weekend into the “master” branch (which at some point will be renamed “main”).

 

Eliot

<ATT0002><draft-ietf-opsawg-sbom-access.txt>