[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [openc2-lang] Comments of Note from the Actuator Profile subcommittee: New Language Element
|
I agree we define the term âswidâ as 4 characters that go in a certain field in OpenC2, but our TC does not define the âblob of textâ in the response to any greater detail than to say itâs âswidâ. I didnât fully understand: âif we start to have CBOR (say) Application Profiles, do we want them to reference the Language Spec for compatibility, or do we want them to reference the SBOM Application
Profile for compatibility. I think the App Profileâ I suspect we can kick that can down the road when we have the specific case. I thought CBOR was a serialization/transfer/transport mechanism and I would advocate the mapping of language terms to âcodesâ for CBoR would be in the Language
Spec just like the JSON is. I thought that is what the âIDâ field was for. Iâm not sure what a âApplication Profileâ is, but I donât think the SBoM Actuator profile would define the CBoR codes unless they were very specific to SBoM. As I said in the other mail, Iâm for the terms being defined in the Language Spec.
But we can address what is in Language vs Transport vs Actuator in the future with actual text and it will be easier to discuss. 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> DO we (open-c2) need to define spidx, swid, or other format? I think not, I think we incorporate be reference. DO we (somewhere in OpenC2) have a list of the formats that are currently accepted? Likely yes. Drilling down, if we start to have CBOR (say) Application Profiles, do we want them to reference the Language Spec for compatibility, or do we want them to reference the SBOM Application Profile
for compatibility. I think the App Profile. tc From: openc2-lang@lists.oasis-open.org <openc2-lang@lists.oasis-open.org> on behalf of duncan sfractal.com <duncan@sfractal.com>
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> 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. tc From: openc2-lang@lists.oasis-open.org <openc2-lang@lists.oasis-open.org> on behalf of duncan sfractal.com <duncan@sfractal.com>
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> 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]