Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Property name for profile-defined Targets #348

Open
davaya opened this issue Sep 27, 2019 · 4 comments
Open

Property name for profile-defined Targets #348

davaya opened this issue Sep 27, 2019 · 4 comments
Assignees

Comments

@davaya
Copy link
Contributor

davaya commented Sep 27, 2019

The Target property table in the CS 1.0 Language Spec Section 3.3.1.2 does not include an example SLPF target that was included in CSPRD 01, but it still has Actuator (3.3.1.3) and Results (3.3.2.2) SLPF examples. But Section 3.1.4 (Extensions) does contain an example Target that is inconsistent with the Args, Actuator, and Results examples contained in the same section.

As discussed in Issue #342, section 3.1.4 contains an incorrect description of NSIDs (which are prefixes used in Type references and have nothing to do with property names). The Target example in that section needs to be fixed, in one of two ways:

  1. Make the target example consistent with the args, actuator, and results examples (the preferred approach):
{
    "action": "delete",
    "target": {
        "slpf": {
            "rule_number": 1234
        }
    }
}

Pull Request #349 assumes that this approach is used, and updates the "pairs" example to use the JSON Pointer standard (RFC 6901) to refer to profile-defined targets.

  1. Make the target property name be a JSON Pointer. This is a confusing approach, but if we want to define targets using property names that are pointers to profile-defined properties, then target property names must follow the RFC 6901 syntax:
{
    "action": "delete",
    "target": {
        "slpf/rule_number": 1234
    }
}
@dmg2
Copy link

dmg2 commented Mar 2, 2020

I always thought this was odd, I am not sure why we went this route, but I believe it was originally on purpose. Perhaps here we can revisit, I rather have uniformity if possible were it makes sense. I like approach one.

@davaya
Copy link
Contributor Author

davaya commented Mar 2, 2020

Approach 1 is the correct structure for OpenC2 commands.

The current odd command structure:

{
    "action": "delete",
    "target": {
        "slpf:rule_number": 1234
    }
}

was originally done on purpose because we needed a name for targets to put in the query pairs response. But people didn't realize that JSON Pointer (RFC 6901) is the standard way to do that. So they used the same odd string as a property name as they did for the query response (https://docs.oasis-open.org/openc2/oc2ls/v1.0/cs02/oc2ls-v1.0-cs02.html#annex-c-design-elements)

        "delete": ["slpf:rule_number"],

The correct way is to define the command normally as in Approach 1, and then use a JSON Pointer string as the name of the target:

        "delete": ["slpf/rule_number"],

@dlemire60
Copy link
Contributor

PR #349, referenced in the opening description of the issue has been merged. What other changes are needed to completely resolve this issue?

@dlemire60
Copy link
Contributor

Discussed at triage; @davaya will take action to review examples and see if they've been fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants