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

Enable TAXII server to check for Interop requirements #154

Open
rpiazza opened this issue Mar 16, 2022 · 1 comment
Open

Enable TAXII server to check for Interop requirements #154

rpiazza opened this issue Mar 16, 2022 · 1 comment
Assignees

Comments

@rpiazza
Copy link
Contributor

rpiazza commented Mar 16, 2022

The TAXII interop document has some restrictions beyond what is in the TAXII spec. Check for these when an command line argument indicates it.

Possible issues:

  • Sorting criteria for the collection endpoint (section 2.1.7) seems to be more restrictive than the spec (section 3.3)
  • TAXII Client MUST support certificate-based authentication
  • Many endpoints do not have a full set of error test cases
  • Section 3.5 – test cases seem redundant
  • The spec says that either 403 or 404 could be returned if there is a mismatch between a get_object request and its read/write permissions, but section 3.5.2 implies it should be a 403
  • The spec says that either 403 or 404 could be returned if can_read is false for the client of the request, but section 3.6, 3.7 and 3.8 says it MUST be a 403
  • The spec says that either 403 or 404 could be returned if can_write is false for the client of the request, but section 3.10 says it MUST be a 403
  • 24-hour requirement for get-status is a MUST
  • No Delete error test cases
  • If we want to use the examples in this document, we need to get the test data
  • Should the error messages in the TAXII spec be the ones returned in the error responses?
  • Custom property names must include a UUID, which is different from the spec.
@rpiazza rpiazza self-assigned this Mar 16, 2022
@rpiazza
Copy link
Contributor Author

rpiazza commented Mar 17, 2022

  • Code Change

    • Sorting criteria for the collection endpoint (section 2.1.7) seems to be more restrictive than the spec (section 3.3)
    • If we want to use the examples in this document as test cases, we need to get the test data
  • Client

    • TAXII Client MUST support certificate-based authentication
  • Misc

    • Many endpoints do not have a full set of error test cases
    • Section 3.5 – test cases seem redundant
    • No Delete error test cases
  • No code change needed

    • The spec says that either 403 or 404 could be returned if there is a mismatch between a get_object request and its read/write permissions, but section 3.5.2 implies it should be a 403
    • The spec says that either 403 or 404 could be returned if can_read is false for the client of the request, but section 3.6, 3.7 and 3.8 says it MUST be a 403
    • The spec says that either 403 or 404 could be returned if can_write is false for the client of the request, but section 3.10 says it MUST be a 403
  • 24-hour requirement for get-status is a MUST

  • Should the error messages in the TAXII spec be the ones returned in the error responses?

  • Custom property names must include a UUID, which is different from the spec.

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

No branches or pull requests

1 participant