Re: [openc2-lang] Comments of Note from the Actuator Profile subcommitte

“We are in substantial agreement. The language TC does not need to know if there are two, or three, or fifteen standard formats. That remains entirely up to the Application Profile.”

We have a substantive disagreement here wrt where I bolded your statement. I would like to specify, in the Language Specification, at least some of the standard formats. I would prefer every term in any OpenC2 Specification to be specified in the Language Specification and I would prefer, when possible, to even include terms in CAP’s when it would remove ambiguity and/or help with intertworking. So, for example, in the case of the SBoM formats; I would request swid, spdx, and cyclonedx be included in the language specification. I personally don’t care if swid, for example, is swid, swid_tag, software_id, or lots of other choices. But I do care that we pick one, and only one, term to represent it whenever it is used in any OpenC2 specification. And the place to do that definition is the language specification. I do agree CAP’s can extend the “list of formats” to longer than the 3 that I proposed. But even there, if someone went to the trouble to put a term in a CAP, then I would tend to favor adding that term to the language specification - unless they were truly obscure or blatantly vendor proprietary.

Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

I welcome VSRE emails. Learn more at http://vsre.info/

From: Toby Considine <Toby.Considine@unc.edu>
Date: Thursday, December 12, 2019 at 11:45 AM
To: "duncan@sfractal.com" <duncan@sfractal.com>, openc2-lang <openc2-lang@lists.oasis-open.org>
Subject: Re: [openc2-lang] Comments of Note from the Actuator Profile subcommittee: New Language Element

We are in substantial agreement. The language TC does not need to know if there are two, or three, or fifteen standard formats. That remains entirely up to the Application Profile.

As to the term report, it is a request to return a structured list, of more than one column, for what may well be more than a thousand similar elements, in a predefined format. I am not sure what the push-back is.

From: openc2-lang@lists.oasis-open.org <openc2-lang@lists.oasis-open.org> on behalf of duncan sfractal.com <duncan@sfractal.com>
Sent: Wednesday, December 11, 2019 11:07 AM
To: Considine, Toby <Toby.Considine@unc.edu>; openc2-lang@lists.oasis-open.org <openc2-lang@lists.oasis-open.org>
Subject: Re: [openc2-lang] Comments of Note from the Actuator Profile subcommittee: New Language Element

‘This may be the precursor to other Profiles for remote situation awareness (“reporting”)’

I do NOT consider SBoM as related to reporting in any way. Note the proposed action (query) and target (features) already existed and “sbom” is being added to the features list as it is similar to ‘profile’ and ‘version’ that are already there. I would consider ‘sbom’ to be more detail on the ‘version’ – and not some form of reporting.

‘the well-known formats are SPDX and SWID’

I would also like to point out there are 3 SBoM formats in wide use today – swid, spdx, and cyclonedx. Swid and spdx came from the license use case. CycloneDx came from the security use case. All 3 formats and do all 5 sbom uses in the ntia report. Since I believe CycloneDx is the most used format today for the security use case, and has the most open source vulnerability tooling, I want to make sure it gets included.

‘we have a language element with a name similar to “Payload”….’

I was proposing ‘sbom-manifest’ to be very specific to this response and the ‘sbom_type’ would be one of swid, spdx, cyclonedx which I think meets the other requirements you mention allowing for conformance checking

Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

I welcome VSRE emails. Learn more at http://vsre.info/

From: openc2-lang <openc2-lang@lists.oasis-open.org> on behalf of Toby Considine <Toby.Considine@unc.edu>
Date: Wednesday, December 11, 2019 at 9:14 AM
To: openc2-lang <openc2-lang@lists.oasis-open.org>
Subject: [openc2-lang] Comments of Note from the Actuator Profile subcommittee: New Language Element

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?)

openc2-lang message