[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-taxii] Re: [EXT] [cti-taxii] The "meaning" of media types in STIX 2.x
Matt, et al.,
Do you have time next week after the normal TC working call to talk through this? Or I can also do Thursday the 20th at 4:00 ET / 2:00 MT? Let me know and I will setup a WebEx.
Bret From: cti-taxii@lists.oasis-open.org <cti-taxii@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Sent: Friday, September 14, 2018 10:38:33 AM To: Matt Pladna; drew.varner@ninefx.com; Jason Keirstead Cc: cti-taxii@lists.oasis-open.org Subject: Re: [cti-taxii] Re: [EXT] [cti-taxii] The "meaning" of media types in STIX 2.x Matt,
Yeah, there might be some inconstancies that we need to address. Perhaps we could setup a call to discuss, with anyone that is interested?
Maybe early next week?
Thanks Bret From: Matt Pladna <mpladna@lookingglasscyber.com>
Sent: Thursday, September 13, 2018 1:47:04 PM To: Bret Jordan; drew.varner@ninefx.com; Jason Keirstead Cc: cti-taxii@lists.oasis-open.org Subject: Re: [cti-taxii] Re: [EXT] [cti-taxii] The "meaning" of media types in STIX 2.x Bret,
I think it makes more sense to stick with endpoints that return STIX bundles so we have one media type for the entire payload.
If we serve a TAXII bundle that’s a TAXII media type, it will contain STIX objects (which are a different media type); my understanding is the HTTP Content-Type is one type for the entire payload.
Also, per the media type definition (https://clicktime.symantec.com/a/1/zUwtlTRepJ1vtepan3ct-OPzSethfi1t85MKpor1y1c=?d=AekN0-15u7XJCOjfMWow13_xZNiCfXbgg7sQULCVh6RAiLL8F01Nk9YTIfwb6KRdN__OsTxPDdCbKkbcry9DpP5JRlyZ_J0Wz9l-8ivHF7SgK8U_PL8NqCGA3M1K4seoXpWltr8OsW0KwqaZBf_ZI6fWs1FfFjhgjKyINXDr9SjtGrOPjvSgIchtK8_uxDGbLOcUSCbvq5oOvfL7zUaDZ-qHHAU8FysOe780uh1VJbbceF8ele1mwAEpz6GAhQ5uwHY0JLBtr47XSM2iILIVVsQzfXkJWsTLR1pkkH6pRjtWWdxLcGCaFzB7U1EjR1O75rflv6LbSUSQh8zvhYDBGKVMYdVCp26Th56QxhzsCKUU0K_nYYwcVh2QcIARzLcKUvEEHm4k3d9krKxAkIcdV4v1rhqXmUj_0JRnMBK1Y9SUXD_WrMDPmW1LuoeQty7WivT3g8BuMqNaTgo%3D&u=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fmedia-types%2Fapplication%2Ftaxii%252Bjson) Note: Despite TAXII searching and returning STIX objects, this format does not encapsulate any CTI content. It is expected that CTI documents will be sent with the appropriate mime-type. For these, consult their own security consideration sections.
I take the above to mean we wouldn’t encapsulate STIX either, but am I interpreting that incorrectly?
Another option I could think of, if the goal is to simplify the media types, is we drop the TAXII content type and make TAXII resources STIX 2 media types instead. The TAXII resources then act as containers/summaries of underlying STIX data, but I’m not sure that would make sense.
Thoughts?
From:
<cti-taxii@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Drew,
I like this idea. If we also defined a Bundle in TAXII (not removing the one from STIX), this would get rid of the weird client behaviors where some endpoints need a TAXII media type and some endpoints need a STIX endpoint.
My suggestion would be:
1) Define a Bundle in TAXII 2) Make all endpoints use TAXII media types 3) Add a filter parameter that allows the client to specify which STIX versions it can support.
Bret
From: drew.varner@ninefx.com <drew.varner@ninefx.com>
This is also my understanding. However, we currently don’t have the ability for a client to tell the TAXII Server what STIX object versions it understands via accept headers.
I don’t think we should use accept headers to tell the server what STIX object versions a client understands. Now that STIX version is an object attribute, I think it’s simply a query parameter on the endpoints.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]