OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

openc2 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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


A work item for the HTTPS Transfer Spec  (link to working version on GH) is to standardize on the path; there an open issue 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 is nearly ready to go to public review. The default topic structure for sending commands is documented in section 2.2; for this purpose the topic would be oc2/cmd/ap/sbom (+/- some other considerations) to listen for SBOM retrieval commands.




David Lemire

IA Systems Engineer

Technical Solutions

302 Sentinel Drive | Annapolis Junction, MD 20701

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


From: openc2@lists.oasis-open.org [mailto:openc2@lists.oasis-open.org] On Behalf Of d.kemp@cyber.nsa.gov
Sent: Wednesday, July 14, 2021 1:36 PM
To: Eliot Lear <elear@cisco.com>; duncan sfractal.com <duncan@sfractal.com>
Cc: TC OpenC2 (openc2@lists.oasis-open.org) <openc2@lists.oasis-open.org>
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.



From: Eliot Lear <elear@cisco.com>
Sent: Friday, July 9, 2021 9:20 AM
To: duncan sfractal.com <duncan@sfractal.com>
Cc: TC OpenC2 (openc2@lists.oasis-open.org) <openc2@lists.oasis-open.org>; Dave Kemp (GOV) <d.kemp@cyber.nsa.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).





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



From: ntia-sbom-framing-bounces+duncan=sfractal.com@cert.org <ntia-sbom-framing-bounces+duncan=sfractal.com@cert.org> on behalf of Eliot Lear via ntia-sbom-framing <ntia-sbom-framing@cert.org>
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 <lear@cisco.com> 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”).





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]