PRD-02 Comments for HTTPS Transfer Spec (in bulk)

[Brian Berliner <Brian_Berliner@symantec.com>]

As a member of the Technical Committee, the OASIS process requires that I send my own comments to the TC directly, as opposed to using the openc2-comments mailing list. As such, I have combined all my comments into this single message (and, hopefully, sent them to the proper list!).

 

These comments are related to Transfer of OpenC2 Messages via HTTPS Version 1.0 PRD-02 (dated April 04, 2019; PDF version).

 

1. Section 1.4, Page 9: Should have a link to the âActive Cyber Defenseâ paper, which is https://www.semanticscholar.org/paper/Active-Cyber-Defense-%3A-A-Vision-for-Real-Time-Cyber-Herring-Willett/7c128468ae42584f282578b86439dbe9e8c904a8

 

2. Section 1.4, Page 9: Should have a link to the âIntegrated Adaptive Cyberspace Defenseâ paper, which is https://www.semanticscholar.org/paper/Integrated-Adaptive-Cyberspace-Defense-%3A-Secure-by-Willett/a22881b8a046e7eab11acf647d530c2a3b03b762

 

3. Section 1.5.2, Page 14: The first example shown for OpenC2 in the spec is not compliant with the spec as it refers to a âuser_accountâ target, which is not part of the language. The very first example that readers see should accurately reflect a compliant command, like a âdeny/file/hashes/sha256â command. I can supply an example if necessary, but using âuser_accountâ definitely feels wrong to me at this spot in the document.

 

4. Section 3.2.2, Page 18: The spec does not use the HTTP âGETâ verb, so the table needs to be corrected.

 

5. Section 3.2.2, Page 19: States that the X-Request-ID header MUST be included, though the language spec says that it is optional for commands that do not âexpectâ a response (like with âresponse_requestedâ: ânoneâ). I think that X-Request-ID SHOULD be supplied but should not be required. That is what the Symantec implementation does, and it works well, as there is no way that the X-Request-ID value can be utilized by this specification (only command_idâs can be queried, not request_idâs currently). NOTE also that section 3.3 on Page 20 adds âif anyâ after the mention of the X-Request-ID field, so we are not consistent with our wording with respect to this header already.

 

6. Section 3.3, Page 20: An HTTP Request that expects a response needs to also include a âAcceptâ header with the value of âapplication/openc2-rsp+json;version=1.0â. The Accept header is standard practice for HTTP-based APIâs.

 

7. Section 4, Page 21: The spec does not use the HTTP âGETâ verb, so the conformance needs to be corrected.

 

8. Section 4, Page 21: The conformance sections requires usage of the response codes defined in Section 3.3, Page 20, but there are no response codes listed there. They are contained in the Language Spec itself and should be referenced there, I suppose.

 

9. Section 4, Page 22: The âtoâ entry in the conformance Table 4-1 is not compliant with the Language Spec, since the Language Spec documents this field as an Array Of Strings, which cannot be included in an HTTP Host header.

 

10. Section B.1.1 and B.1.2, Pages 24-25: The Example includes a X-Request-ID header that is acceptable but not aligned with the SHOULD part of the Language Spec, which says that the request_id SHOULD be a UUIDv4. I think our examples SHOULD follow the suggestions of the spec, so this header should be changed to be an actual UUIDv4 valueâ