Re: [openc2-lang] Comments of Note from the Actuator Profile subcommittee: New Language Element

[Dave Lemire <dave.lemire@g2-inc.com>]

FYI, there's a corresponding Slack thread, for people who prefer to engage there.ÂÂ
https://openc2-community.slack.com/archives/C2QMQDCBV/p1576073770036100

Dave

David Lemire, CISSP

Systems Engineer

HII Mission Driven Innovative Solutions (HII-MDIS) â formerly G2, Inc.

Technical Solutions Division

302 Sentinel Drive | Annapolis Junction, MD 20701

Email: dave.lemire@g2-inc.com

Work: 301-575-5190 | Mobile: 240-938-9350

On Wed, Dec 11, 2019 at 9:14 AM Considine, Toby <Toby.Considine@unc.edu> wrote:

As noted in the minutes of Mondayâs meeting, the SBoM Actuator Profile is entering into rapid development. The Software Bill of Materials is a critical component of the Comply to Connect

ÂThe SBoM draft will come to the language SC as a set of new requirements for remote query. This may be the precursor to other Profiles for remote situation awareness (âreportingâ). More on that in another note.

ÂFor this message, I want to focus on a new language element, one for something that is a BLOB as far as OpenC2 knows. SBoM already has a few standard formats, and none of them are JSON. In the case of SBoM, they are XML based, and there is some hint that the next generation of those formats will skip JSON and go to CBOR. We probably want to restrict these blobs to text-based, using the character-sets already legal in OpenC2.

ÂTo the Language SC, those formats do not matter, although they do to the specific Actuator Profile. In this case, the well-known formats are SPDX and SWID. In another request they could be something else.

I think we have a language element with a name similar to âPayloadâ. The language spec makes no assertions as to the content or format of a Payload. The notion of defining a custom serialization of a specific payload for OpenC2, one which must then be converted back into the original format for use was specifically rejected in the Actuator Profile call.

ÂA conforming Actuator Profile may request a response that has one or more Payloads. A Profile expecting a Payload MUST define the conformance expectations for the Payload. It is preferred that the conformance expectations be defined by reference to an existing specification.

Â(This last pointâpre-existing specification. Is it required? If there is no pre-existing specification, why would we define in a format other than JSON?)

Âtc