Re: [EXT] [openc2-lang] What does "transport agnostic" mean?

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

-------- Original Message --------
Subject: [openc2-lang] Re: [EXT] RE: [openc2-lang] New properties
From: Bret Jordan <Bret_Jordan@symantec.com>
Date: Mon, October 09, 2017 1:13 pm
To: "duncan@sfractal.com" <duncan@sfractal.com>,
"openc2-lang@lists.oasis-open.org" <openc2-lang@lists.oasis-open.org>

We keep talking about OpenC2 as a stand alone, protocol and transport agnostic solution. As such, we can not assume or rely on any thing from the transport. Thus, if we do not bind OpenC2 to a MTI transport where we can guarantee that certain pieces of content are there, then we need to define in them in our spec.

Knowing when a command was created / modified is required for basic versioning of commands. Too often this group assumes incorrectly that when you issue a command to a device, it will process it in real-time. A device may need to queue that command for some period of time before it can actually process it.

From a logging and auditing trail standpoint, it would be good to have more information about commands. Aka, what is the command ID, when was the command created, who created the command etc. The person that created the command may NOT be the person that is sending it over the wire.

UUIDv4 vs UUIDv5 is a fun debate. UUIDv5 is a valid solution if the content in the payload is never going to change, meaning there is never going to be an updated version of it. If there is, then you run in to a problem, because the ID changes.

Yes, I want a structure like:

{

"id": "",

"created": "",

"modified": "",

"target": "",

"actuator": "",

etc

}

Bret

From: openc2-lang@lists.oasis-open.org <openc2-lang@lists.oasis-open.org> on behalf of duncan@sfractal.com <duncan@sfractal.com>
Sent: Wednesday, October 4, 2017 9:25:57 PM
To: openc2-lang@lists.oasis-open.org
Subject: [EXT] RE: [openc2-lang] New properties

Bret,

To be clear wrt ID - I think you are asking:

1) move id from being under command-option to being a peer to action/target/actuator/command-option

2) id to be mandatory (I'm presuming you meant that based on #1)

3) a specific format for the ID - UUIDv4

Did I get it right? If so, I think they are 3 separate, related issues. #2 got some discussion at the last LSC meeting.

Wrt UUIDv4 - are there other choices we should consider? Why v4 not v5? (which I think is a one-time vs reproducible argument that might be like a religious war). Note I don't know enough to favor one or other - I'm just asking since someone eventually will.

Wrt created/timestamp - Am I correct that you would prefer this as a 'top level' part of the json as opposed to it being under command-options? Could you explain logic of when you'd prefer top-level vs when under command-options? Or would you prefer all command-options to be top-level?

Wrt created/timestamp - could you provide the usecase for including this in the openc2 language? In particular why it's in the json itself as opposed to being in the transport (particularly in the STIX case which has one of it's own) or in the logging? I'll confess the use cases that interest me (as sFractal, not co-chair) the most are 2 authenticated entities talking directly so there is no transport delay to speak of so the producer doesn't need to send the consumer the time it was sent.

Similarly for creator/author - could you provide the use case? Ditto my previous confession since directly connected mutually-authenticated entities know the other end.

I agree the multiple target commands have issues we have yet to address. I would think the command id and target specifiers would be sufficient but maybe i'm just not seeing the use case you have in mind where that would not work. I think I may be stuck in the 'simple' use cases where we know the actuator(s) we are sending to. In the 'variable' cases the STIX COA have been discussing, the actuator/specifiers are not know a priori. But I'm not sure you could serial number it if you couldn't target-specifier it. I agree it needs more discussion.

My preference would be kick multiple-targets down the road until after January's 1.0. I fine with it being top of the list for next version but personally (Duncan as sFractal, not co-chair) I'd rather get the 'simple' use cases handled first.

Joe, Sounil,

This might be a good area to ask for input from the cyber-user council as to their priorities and urgencies.

Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

-------- Original Message --------
Subject: [openc2-lang] New properties
From: Bret Jordan <Bret_Jordan@symantec.com>
Date: Wed, October 04, 2017 2:37 pm
To: "openc2-lang@lists.oasis-open.org"
<openc2-lang@lists.oasis-open.org>

I would like to propose that the language SC consider adding the following top-level properties to all commands:

id (UUIDv4)

created (timestamp)

creator or author or something (an ID to a STIX Identifier or some sort of other identity)

We should also have some sort of serial number as well. So that if you have a command with and ID of 1234 and you issue that command to 400 systems, you will need some way of knowing which systems / serial numbers accepted and processed that command successfully.

Bret

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

openc2-lang message