RE: Discussion at F2F for the beyond-JSON issue

["Considine, Toby" <Toby.Considine@unc.edu>]

The current Specification, named “Stateless Packet Filter”, is actually “Stateless Packet Filter encodes in JSON”. That’s OK, the name does not need to match exactly.

 

So along the way we have created general rules for encoding OpenC2 in JSON. It is likely that each of these rules should be identical for other encodings in JSON. We should not have a different specification for how, say. the X-Correlation-ID is crafted.

 

A perhaps revealing question is what might something different be.

 

1. If we create “SLPF in COAP” or “SLPF in XML”, do any of the lexical elements change? Cardinality elements change? Anything else?
2. If we create a more multicast version of SLPF (Addressed to a CIDR or to list of addresses, or to a fabric), what relation does it have to the current specification?

 

We are coming close to stating rules for conforming specifications, a topic  that was shot down at the last F2F.

 

tc

 

 

 

From: openc2-imple@lists.oasis-open.org <openc2-imple@lists.oasis-open.org> On Behalf Of duncan sfractal.com
Sent: Monday, January 7, 2019 8:03 AM
To: openc2-imple@lists.oasis-open.org
Subject: [openc2-imple] Discussion at F2F for the beyond-JSON issue

 

I think “HTTPS-1: make JSON support required, allow other serializations” may require more discussion. Given how long it was discussed in SC meetings I’m not sure it won’t some discussion in F2F. Is there a writeup of the proposed solution on requiring JSON and is that wording in SLPF and/or in transport spec? 

 

My concern is interworking and supplier lock-in. I think it’s possible (but haven’t seen the wording) to specify ‘require JSON’. I object to the ‘allow other serializations’ unless the wording 

- specifies how interworking is accomplished (which was talked about but I haven’t seen text)

- which ones are optional and/or specify how to do supplier extensions

 

My concern is I believe it would be possible to create supplier solutions that would not interwork, would lock you in to that supplier, yet would be compliant.  If we are going to allow XML serialization (which I am against) then I think we should specify how to do that in it’s own spec with it’s own conformance to ensure interoperability. Ditto for any other serialization such as YAML, COAP, protobuf, vendor-proprietary, etc. Following the “keep it simple for now”, I think Version 1 should just be JSON - but I won’t object if we find wording that meets my two bullets above.

 

iPhone, iTypo, iApologize

 

Duncan Sparrell

sFractal Consulting, LLC

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

 

---

From: openc2-imple@lists.oasis-open.org on behalf of Dave Lemire <dave.lemire@g2-inc.com>
Sent: Friday, January 4, 2019 10:50 AM
To: openc2-imple@lists.oasis-open.org
Subject: [openc2-imple] Characterizing HTTPS Spec issues for the F2F

 

IC-SC Members

 

(this message is cross-posted to Slack #implementation; respond where ever you prefer).

 

Following Joe Brule's lead, I'm trying to bin up the HTTPS Specification comments for discussion at the F2F meeting.  Here's my current proposed segregation into "not too controversial" and "need deeper discussion"; I'd like feedback on whether the SC members believe any issue is in the wrong bin. Some discussion of these has taken place in IC-SC meetings on December 19th and January 2nd.  I'm using theHTTPS issue numbers in the CRM, with a quick summary label. Please follow the link to the CRM to access more more detail about the issues and review specific change proposals in pull requests.

 

Not Too Controversial

• HTTPS-1: make JSON support required, allow other serializations
• -2: HTTP date header should be option, align with RFC
• -3: Example messages should use example dates, not template
• -4: Add Goal subsection into Section 1 to align with the other specs
• -5: Align message terminology with L-Spec:  "message elements", not "head information"
• -6: Change "specification describes" to "document specifies" in abstract
• -7: Delete "one or more" regarding selection of transfer specifications
• -8: add non-normative IACD references 
• -9: add targets as something an AP may define in description of APs
• -10: Clarify explanation of layering of security solutions 
• -11: Remove references to subcommittees in Fig 1 (documentation / layering model) 
• -12: Change "transport" to "transfer"
• -13: Clarify wording of specification intent
• -14: Remove JSON from message lines in Figs 2 & 3
• -15: Thoroughly link conformance statements back to requirements text
• -16: Add RFC 7231 to specification of Date format in conformance
• -17: Fix unmatched brackets in example message
• -19: Remove "verbose" in relation to JSON (relates to -1)
• -21: Remove mentions of supporting notifications 
• -24: Remove any support for TLS / SSL versions prior to TLS 1.3
• -25: Add normative / non-normative intro labels for document sections
• -29: Specify base64url encoding for X-Correlation-ID (was previously unspecified)

Note: Items 4, 7, 8, 9, 10, 11, 12 & 13 apply to Section 1 content; the editors' intent is that content will be uniform across the three specifications for 1.0 through 1.7 (which is 1.6 in PR draft of HTTPS spec due to missing Goal section (issue 4)).

 

Require Deeper Discussion

• -18: cancel example (dependent on command-id issue)
• -20: "transport independent" (dependent on command-id issue)
• -22: align with L-Spec on command-id / request-id (dependent)
• -23: remove polling / "backward" -- SC consensus in favor
• -26: require mutual authentication -- SC consensus in favor
• -27: authentication requirements (remove PK certs) -- SC consensus in favor, possible conformance issue
• -28: remove "id_ref" from example responses (dependent on command-id issue)

Dave

 

David P. Lemire, CISSP
  OpenC2 Technical Committee Secretary
  OpenC2 Implementation Considerations SC Co-chair
  Contractor support to NSA
Email: dave.lemire@g2-inc.com
Office: 301-575-5190 / Mobile: 240-938-9350