[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [openc2-lang] RE: [EXT] [openc2-lang] What does "transport agnostic" mean?
Inline. From: <openc2-lang@lists.oasis-open.org> on behalf of "Kemp, David P" <dpkemp@radium.ncsc.mil> There is a difference in the way CIA is accomplished and the way graph-linking command unique identifiers are accomplished. The OpenC2 *Language* has had a command option “command_id” since the Forum days. It is currently optional, but it could be made mandatory as discussed
in the Language SC meeting, and its definition could be expanded to include more specific types of unique identifiers such as UUID, as opposed to a generic string. AT: I read the language spec last night and thought why was the command_id not mandatory? I agree it should be. The OpenC2 *Implementation Considerations* has requirements for CIA. Things like creator and creation time are covered by the implementation, they are
not part of the language. AT: Having just read this document last night, it’s an extremely verbose document that reads more like a whitepaper and is hard to pull out the concrete
requirements. I suggest we consider a more succinct way of communicating requirements for any products to implement OpenC2.
Maybe this is simply achieved by making sure that the actuator documents define the requirements for each system implementing OpenC2.
As far as I know, nobody says “We keep talking about CTI as a stand alone, protocol and transport
agnostic solution.” CTI is not a solution, it is a TC developing STIX and TAXII. OpenC2 is a TC developing a language specification and implementation considerations.
If using OpenC2 as the name of both a TC and a language is a source of confusion, perhaps we should rename the TC so that its work products are more easily distinguished, and reserve the word OpenC2 for just the language specification, not the transport and
security considerations. AT: I don’t think the TC needs to be renamed but I do think we need to firm up the terminology and how things are referenced in the documents. For example,
sometimes the document refers to the ‘OpenC2 specification’ when in fact no such specification exists. So I suggest we make sure that all references to specifications and documents are accurately captured in the text so that there is no ambiguity in what is
being referenced. See some of my comments to that effect in the language spec. Dave “ From: openc2-lang@lists.oasis-open.org [mailto:openc2-lang@lists.oasis-open.org]
On Behalf Of Bret Jordan There is a difference between relying on high-level elements like the CIA triad, and ensuring that certain things are there, like unique IDs that can be used in a graph, serial numbers for messages
so that you know which version was acted on. Bret From: openc2-lang@lists.oasis-open.org <openc2-lang@lists.oasis-open.org>
on behalf of duncan@sfractal.com <duncan@sfractal.com> Bret, I do not agee with your statement: "...OpenC2 as a stand alone, protocol and transport agnostic solution. As such,
we can not assume or rely on any thing from the transport...".
I think we can assume and rely on requirements we put in the implementation guidance without specifying the details of how they are met. We can assume CIA - confidentiality,
integrity, and availability to whatever extent the users require ie the message does reach the recipient (availability), that it was not changed in transit (integrity), that the link is secure (confidentiality). How much effort is required for each of these
and what techniques are used is up to the users and implementation community for a particular interworking scenario. And the fact we haven't recommended any transport alternatives yet (although we have, https-api, stix, etc) doesn't mean we won't. I think
we will recommend several and interworking will still work and we will have CIA. Duncan Sparrell sFractal Consulting LLC iPhone, iTypo, iApologize
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://clicktime.symantec.com/a/1/grWHEt99PMPpJuwVv88LO3seRvCSUH6IZXCDTf6c6GI=?d=w_eanSzhZqvFDdRP_jjDQgSLkGjG6nBcmKbaYEoLl7r-s65c83aI8E6vrhmVP2KzuE95V4RyiXr_TUCBOdkvdugfs_VsiAFhKrz7VqIn9N4Flbws1yZIA1ATwJVjTxYUQrgEyIThkOzp1XWLZ5IT-i9_L1BoHp32kMdxGmNRvmmqDyDkowGImF7Zj6jT-AEhqCp8RiHaKNYzikQ74Fg1wgSeG2CxQ038TPJhNm90vgyt4yizStcG_srEADScLhOH9NzwVkUMyTbAzQJMmXjwK_6rTRl_nSd64izC4aTuuNEBFsgYSQEsuIWfBBdYtV1OyJ71GHF1umMPH6hDoR61arL0nnqBdhJjYBFU8yAFpedKACFA7ZmTOQMZDgeyL6EHFjrfXvZTqSKaUVdSswCvFmcQaA7SrDR98OnWOCUxJ1PPSInO1J-dMkvVqJrNM4mydNoAaj7pxDftPcOWm9b0D3B89YnzPQk8YOHxrbVxLLiuv_4E8srDp-fJM9Ahp47hf9H2EU--pfXqfQ4xiA%3D%3D&u=https%3A%2F%2Fwww.oasis-open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]