Proposal: Remove Content Binding IDs for MIME Types

[MarkDavidson]

Currently, Content Binding IDs are used to identify content types in a TAXII Message (e.g., content of STIX 1.1.1). However, experience has shown that MIME types are increasingly used as Content Binding IDs (e.g., S/MIME) and that all uses of Content Binding IDs that are not MIME Types (e.g., STIX versions) could be implemented as a MIME Type. Additionally, the Content Binding ID concept is redundant with, and does not add any value to, the MIME Type concept. This change proposes that Content Binding IDs are removed from the TAXII vocabulary in favor of MIME Types so that TAXII does not ‘reinvent the wheel’.

Since MIME object processing is already prevalent in the internet, the hope is that TAXII's use of MIME objects will allow for more generalized processing.

Edit: Conversation shows that my original wording was not clear. The proposal is to change the allowable values of the Content_Binding field to be MIME Types instead of Content Binding IDs. The proposal is not to remove the Content_Binding field.

[jordan2175]

Sounds like a great idea.

[terrymacdonald]

Hi Mark,

I like this idea a lot. It seems like ti will give a lot more flexibility with the future types of data TAXII could transport.

Cheers Terry MacDonald

On 26 March 2015 at 01:10, MarkDavidson notifications@github.com wrote:

Currently, Content Binding IDs are used to identify content types in a TAXII Message (e.g., content of STIX 1.1.1). However, experience has shown that MIME types are increasingly used as Content Binding IDs (e.g., S/MIME) and that all uses of Content Binding IDs that are not MIME Types (e.g., STIX versions) could be implemented as a MIME Type. Additionally, the Content Binding ID concept is redundant with, and does not add any value to, the MIME Type concept. This change proposes that Content Binding IDs are removed from the TAXII vocabulary in favor of MIME Types so that TAXII does not ‘reinvent the wheel’.

Since MIME object processing is already prevalent in the internet, the hope is that TAXII's use of MIME objects will allow for more generalized processing.

— Reply to this email directly or view it on GitHub https://github.com/TAXIIProject/TAXII-Specifications/issues/55.

[jordan2175]

I also do not think this is a breaking change as newer version could just ignore previously defined values. And since it is not required, older versions would not care if it was not there. So I think we should do this soon.

[traut]

As far as I understand, it is possible to specify desired content_binding in a poll request. This allows clients to request only the content they can process.

I can't see how this can be supported with MIME types. Client has no way of specifying required types (content_binding field in Poll Request message will be removed) and server have no way of filtering out the types (because MIME type is inside content block) without parsing the content.

How would that work?

[jordan2175]

Right now we have the X-Taxii-Accept to identify which type of TAXII formatting the client wants in return.

Example: "X-Taxii-Accept", urn:taxii.mitre.org:message:json:1.0

I am wondering if we should add X-Stix-Accept as a header option.

Example: "X-Stix-Accept", urn:stix.mitre.org:message:xml:1.1

In this example the user would be requesting XML encoded STIX in a JSON encoded TAXII message.

[terrymacdonald]

Hi Brett,

TAXII can also carry CAP. So I'm not a fan of having a definitive X-Stix-Accept header as we would also need a X-Cap-Accept header. It doesn't seem extensible.

Doesn't the Poll Request have the field in it to indicate an acceptable Poll Response? As does the Manage Collection Subscription Request. Isn't that enough to give the TAXII Server a heads up on the content types you are willing to receive?

Cheers

Terry MacDonald | STIX, TAXII, CybOX Consultant

M: +61-407-203-026 E: terry.macdonald@threatloop.com W: www.threatloop.com

https://www.threatloop.com

Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

On 14 May 2015 at 04:49, jordan2175 notifications@github.com wrote:

Right now we have the X-Taxii-Accept to identify which type of TAXII formatting the client wants in return.

Example: "X-Taxii-Accept", urn:taxii.mitre.org:message:json:1.0

I am wondering if we should add X-Stix-Accept as a header option.

Example: "X-Stix-Accept", urn:stix.mitre.org:message:xml:1.1

In this example the user would be requesting XML encoded STIX in a JSON encoded TAXII message.

— Reply to this email directly or view it on GitHub https://github.com/TAXIIProject/TAXII-Specifications/issues/55#issuecomment-101774129 .

[jordan2175]

Very good point about CAP. Maybe a more general header object or the use of MIME Types like @MarkDavidson brought up.

[terrymacdonald]

I like the MIME types idea rather than adding a new header. The closer we can get to vanilla HTTP the better IMHO. It also means that if we move to other protocols in the future that use MIME Types for identification then it makes that easier too (we don't need to come up with another way of identifying content). https://github.com/TAXIIProject/TAXII-Specifications/issues/55

Cheers Terry MacDonald

On 14 May 2015 at 07:21, jordan2175 notifications@github.com wrote:

Very good point about CAP. Maybe a more general header object or the use of MIME Types like @MarkDavidson https://github.com/MarkDavidson brought up in another issue.

— Reply to this email directly or view it on GitHub https://github.com/TAXIIProject/TAXII-Specifications/issues/55#issuecomment-101819525 .

[traut]

I'm confused. Is the proposal about changing content_binding field into another field that supports MIME types? This way filtering will still work. I think this is a nice feature to have in TAXII.

I would argue that this field should be inside the message because it is just another "filter" value, together with *_timestamp_label fields.

[terrymacdonald]

That's how I read Marks suggestion Sergey, but we'd need Mark to confirm.

Not all messages will have content inside them. I'd argue its only useful when the TAXII message contains content that requires it. That said, if we are going to need to support TAXII streaming then maybe we need something different again?

Cheers

Terry MacDonald | STIX, TAXII, CybOX Consultant

M: +61-407-203-026 E: terry.macdonald@threatloop.com W: www.threatloop.com

https://www.threatloop.com

Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

On 14 May 2015 at 20:00, Sergey Polzunov notifications@github.com wrote:

I'm confused. Is the proposal about changing content_binding field into another field that supports MIME types? This way filtering will still work. I think this is a nice feature to have in TAXII.

I would argue that this field should be inside the message because it is just another "filter" value, together with *_timestamp_label fields.

— Reply to this email directly or view it on GitHub https://github.com/TAXIIProject/TAXII-Specifications/issues/55#issuecomment-101989504 .

[MarkDavidson]

All,

My apologies for any confusion from the original wording. The proposal is to change the allowable values of the <Content_Binding> field, not to remove the field. For reference, the Content_Binding field indicates the formats that are allowed in the Poll_Response's Content_Blocks

For instance, right now a Poll Request might contain the following:

<Poll_Parameters>
   <Content_Binding binding_id="urn:stix.mitre.org:xml:1.1.1"/>
</Poll_Parameters>

The binding_id field currently contains a Content Binding ID. The proposal is to modify the allowable values to be MIME Type identifier (e.g., text/plain) and consequently Content Blocks must be MIME objects.

I will update the original post with some clarifying information.

I second @terrymacdonald's preference for moving TAXII closer to vanilla HTTP.

[jordan2175]

I was kind of hoping that we could do this in the HTTP header and pull it out of the TAXII message. My reasoning for doing that, is people can learn what you offer or are requesting by just parsing the HTTP header. This will allow you to more easily parse the TAXII message. If you only include this type of info in the taxii message, then you can get in to a chicken and egg problem.

[traut]

Another angle to that: I think it is important to rely on the notion that TAXII request message fully represents a data query and saving TAXII message is enough for bookkeeping. If content-filtering logic is placed in HTTP header, server would have to save HTTP headers as well. This would make whole HTTP message a data query. Which may simplify parsing but will complicate server logic overall.

I would suggest moving as many TAXII-transport related fields into the headers (TAXII Spec version, spec binding version, etc) but leaving content-related fields (content type, begin/end timestamp, offset/limit, etc) in the message body.

Though, this is an implementation detail. I suspect this issue is about TAXII Spec change and not about TAXII Spec implementation (Binding).

[terrymacdonald]

I would agree with Sergey here. Its important to ensure that each layer is contained within the next layer, and that there is no 'leakage' across boundaries. Otherwise we potentially cause ourselves future problems but losing our modularity.

Cheers

Terry MacDonald | STIX, TAXII, CybOX Consultant

M: +61-407-203-026 E: terry.macdonald@threatloop.com W: www.threatloop.com

https://www.threatloop.com

Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

On 16 May 2015 at 06:51, Sergey Polzunov notifications@github.com wrote:

Another angle to that: I think it is important to rely on the notion that TAXII request message fully represents a data query and saving TAXII message is enough for bookkeeping. If content-filtering logic is placed in HTTP header, server would have to save HTTP headers as well. This would make whole HTTP message a data query. Which may simplify parsing but will complicate server logic overall.

I would suggest moving as many TAXII-transport related fields into the headers (TAXII Spec version, spec binding version, etc) but leaving content-related fields (content type, begin/end timestamp, offset/limit, etc) in the message body.

Though, this is an implementation detail. I suspect this issue is about TAXII Spec change and not about TAXII Spec implementation (Binding).

— Reply to this email directly or view it on GitHub https://github.com/TAXIIProject/TAXII-Specifications/issues/55#issuecomment-102523426 .

[jordan2175]

@traut Do you want to throw out a straw proposal on what you would like to see, in regards to this comment? I think I agree with you and Terry, I just want to make sure I fully understand. Once we can all get on board with it, we can make a formal proposal for the next TAXII spec and we can implement it in the JSON message binding. I held off on implementing the message_binding in the JSON spec until w figured out this issue.

I would suggest moving as many TAXII-transport related fields into the headers (TAXII Spec version, spec binding version, etc) but leaving content-related fields (content type, begin/end timestamp, offset/limit, etc) in the message body.