[TAXII] JSON Message Binding Specification for TAXII v0.3

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[TAXII] JSON Message Binding Specification for TAXII v0.3

Jordan, Bret
All,

Here is version v0.3 that includes TAXII messages up through 3.7, the Managed Collection Subscription Response.  As a side note, I should be finished with the first full draft by end of week.  Please review and give comments, feedback, suggestions, etc.. 

A few points in regards to the JSON style used in this spec.

1) I tried to follow the XML field names as close as possible, albeit they are all lower case instead of some fields being first character upper and others being all lower case (this is what I am proposing for JSON STIX in the JSON working group).  I figured by doing this, it would be super easy to process the field names through a to_lc() method.  

2) Because of the choice to follow the XML field names, some field names seem long and overly verbose.  I hope that in a future version we can greatly reduce some of these and clean it up a bit.  So unless there is over-whelming feedback to do it now, I will stay lock-n-step with XML for this first version.

3) Some of the object structure in XML seem redundant and appears to me that it could be simplified.  I will propose changes and options after this spec is ratified.  

4) In general I have chosen to go with arrays of objects instead of just objects or just arrays in a lot of places. This more accurately follows the XML and allows for various other things.  Please see my other posts to understand the details of why I went this way..  I know this is not ideal, but lets get this first version done and approved, then we can start looking at how to make things cleaner and more efficient.  

I hope that we can get this spec approved and ratified quickly and get tooling support for it in the next month or so.  This will then give organizations a choice for TAXII, either TAXII XML Messages or TAXII JSON Messages.  And yes, you can stick XML STIX inside of a TAXII JSON Message until we get the JSON STIX stuff done (which is a different animal).






Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 


TAXII_JSON_Message_Binding_Specification_v0.3.pdf (314K) Download Attachment
signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] JSON Message Binding Specification for TAXII v0.3

mdavidson

Bret,

 

I have some comments. I’ll delineate each one with a # Header

 

# Overall question

My overall question is – what does a JSON Message Binding add to TAXII? ( I mean this as a friendly challenge of your ideas, so please take it that way)  Your emails have described a vision for distinct ecosystems that each use their preferred “flavor” of TAXII – JSON/SSL, XML/HTTP, and what have you. To me, this sounds like the balkanization of what should be one standardized ecosystem (at least from a technology perspective). Why are we bothering to create a standard if we’re going to encourage heterogeneity? My personal opinion is that everyone should be implementing the same thing because the goal is interoperability.

 

I think we have to remember the overall goal: Improved defenses and situational awareness through the sharing of cyber threat information. If you have important information I can’t access because you use JSON/SSL and I use stone tablet (our developers prefer stone tablets) over carrier pigeon, we’ve failed.

 

I realize I’m on a bit of a soapbox here, so I’ll transition to a technical discussion. My main point is that if multiple message were to become a part of TAXII, it would have one of two impacts: balkanize the ecosystem; or everyone organically chooses one message binding for the sake of interoperability.

 

# JSON Representation – list vs array of objects

 

I think it might make sense to discuss the optimal JSON form a bit more. For instance, your TAXII Discovery Response example includes this snippet:

 

"message_bindings" : [

   {

     "value" : "urn:taxii.mitre.org:message:json:1.1"

   },

   {

     "value" : "urn:taxii.mitre.org:message:xml:1.1"

  },

]

 

It seems to me that a more succinct representation with identical semantics would be:

"message_bindings" : ["urn:taxii.mitre.org:message:json:1.1", "urn:taxii.mitre.org:message:xml:1.1"]

 

I think that following the XML is useful to a point, especially with naming. However, I think mirroring the structure of XML in a JSON representation doesn’t leverage some of (IMO) JSON’s best attributes when compared to XML: a close mapping to lower level programming structures/primitives (arrays, ints, strings, etc) and less structure.

 

IMO, the representation I have suggested requires less code to translate between an on-the-wire representation and an in-memory representation of the same information.

 

# Extended Headers

Recall that in TAXII, recipients SHOULD ignore extended headers they don’t understand (TAXII Services Spec, Section 4.3). The Extended Header field is intended to be an area where specific communities can add functionality to TAXII without having to go outside the spec (think HTTP/SMTP X-Headers).

 

As for a concrete example, I’ll use a feature that was not in TAXII 1.0 and was added to TAXII 1.1: Destination Collection Name. Inbox Messages in TAXII 1.0 did not contain any mechanism for communicating that the content contained in the Inbox Message was destined for a particular Data Collection. Therefore, implementations could (and a few, very few, did – there were another solution that was more common) use an extended header with a name of “Destination_Collection_Names” and an array of values containing the intended Destination Collections (there’s some history here regarding Collection/Feed, but that’s a tangent for this paragraph). Of course, this functionality depends on both TAXII endpoints to implement and respect the Destination Collection Name extended header. There are not any extended headers that are implemented community-wide today.

 

So, for instance:

<taxii:Extended_Headers>

   <taxii:Extended_Header name=”destination_collection_name”>name1</taxii:Extended_Header>

   <taxii:Extended_Header name=”destination_collection_name”>name2</taxii:Extended_Header>
</taxii:Extended_Headers>

 

Thank you. Comments and thoughts are welcome.

-Mark

 

From: Jordan, Bret [mailto:[hidden email]]
Sent: Monday, March 23, 2015 7:02 PM
To: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: [TAXII] JSON Message Binding Specification for TAXII v0.3

 

All,

 

Here is version v0.3 that includes TAXII messages up through 3.7, the Managed Collection Subscription Response.  As a side note, I should be finished with the first full draft by end of week.  Please review and give comments, feedback, suggestions, etc.. 

 

A few points in regards to the JSON style used in this spec.

 

1) I tried to follow the XML field names as close as possible, albeit they are all lower case instead of some fields being first character upper and others being all lower case (this is what I am proposing for JSON STIX in the JSON working group).  I figured by doing this, it would be super easy to process the field names through a to_lc() method.  

 

2) Because of the choice to follow the XML field names, some field names seem long and overly verbose.  I hope that in a future version we can greatly reduce some of these and clean it up a bit.  So unless there is over-whelming feedback to do it now, I will stay lock-n-step with XML for this first version.

 

3) Some of the object structure in XML seem redundant and appears to me that it could be simplified.  I will propose changes and options after this spec is ratified.  

 

4) In general I have chosen to go with arrays of objects instead of just objects or just arrays in a lot of places. This more accurately follows the XML and allows for various other things.  Please see my other posts to understand the details of why I went this way..  I know this is not ideal, but lets get this first version done and approved, then we can start looking at how to make things cleaner and more efficient.  

 

I hope that we can get this spec approved and ratified quickly and get tooling support for it in the next month or so.  This will then give organizations a choice for TAXII, either TAXII XML Messages or TAXII JSON Messages.  And yes, you can stick XML STIX inside of a TAXII JSON Message until we get the JSON STIX stuff done (which is a different animal).

 

 

Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] JSON Message Binding Specification for TAXII v0.3

Jordan, Bret
Mark,

Really great feedback.  Thanks for taking the time to send it..  For your first question, of why, let me quickly address that so we can move forward….  

I believe, based on feedback I have gotten from the community and my personal inquiries to lots of groups, that our adoption rates will increase if we offer JSON.  I also believe JSON will allow groups to get faster performance which is currently hindering adoption and will be easier for developers to implement in a plethora of languages and platforms.  And the TAXII specification allows the creation of other Message Bindings to address the issues I have brought up and have heard from lots of people:

"Message Binding Specifications - A Message Binding Specification defines requirements for representing TAXII Messages in a particular format (e.g., XML). There may be multiple Message Binding Specifications created for TAXII where each Message Binding Specification defines a binding of TAXII Messages using a different format.” [1]


## back to our regularly scheduled program

I like your ideas about the arrays and such, thanks for pointing that out and helping to make the JOSN version better. I will work on making those changes today and get a new version out to the list tomorrow.  I will go through the document and see if I can find other ways of improving the JSON, so if anyone else has feedback, please let me know..  In a future version I would really like to simplify some of the field names, unless we get a general consensus from you and the community that we should do it now.  Some of the field names are just very verbose.  



Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Mar 24, 2015, at 9:10 AM, Davidson II, Mark S <[hidden email]> wrote:

Bret,
 
I have some comments. I’ll delineate each one with a # Header
 
# Overall question
My overall question is – what does a JSON Message Binding add to TAXII? ( I mean this as a friendly challenge of your ideas, so please take it that way)  Your emails have described a vision for distinct ecosystems that each use their preferred “flavor” of TAXII – JSON/SSL, XML/HTTP, and what have you. To me, this sounds like the balkanization of what should be one standardized ecosystem (at least from a technology perspective). Why are we bothering to create a standard if we’re going to encourage heterogeneity? My personal opinion is that everyone should be implementing the same thing because the goal is interoperability.
 
I think we have to remember the overall goal: Improved defenses and situational awareness through the sharing of cyber threat information. If you have important information I can’t access because you use JSON/SSL and I use stone tablet (our developers prefer stone tablets) over carrier pigeon, we’ve failed.
 
I realize I’m on a bit of a soapbox here, so I’ll transition to a technical discussion. My main point is that if multiple message were to become a part of TAXII, it would have one of two impacts: balkanize the ecosystem; or everyone organically chooses one message binding for the sake of interoperability.
 
# JSON Representation – list vs array of objects
 
I think it might make sense to discuss the optimal JSON form a bit more. For instance, your TAXII Discovery Response example includes this snippet:
 
"message_bindings" : [
   {
     "value" : "urn:taxii.mitre.org:message:json:1.1"
   },
   {
     "value" : "urn:taxii.mitre.org:message:xml:1.1"
  },
]
 
It seems to me that a more succinct representation with identical semantics would be:
"message_bindings" : ["urn:taxii.mitre.org:message:json:1.1", "urn:taxii.mitre.org:message:xml:1.1"]
 
I think that following the XML is useful to a point, especially with naming. However, I think mirroring the structure of XML in a JSON representation doesn’t leverage some of (IMO) JSON’s best attributes when compared to XML: a close mapping to lower level programming structures/primitives (arrays, ints, strings, etc) and less structure.
 
IMO, the representation I have suggested requires less code to translate between an on-the-wire representation and an in-memory representation of the same information.
 
# Extended Headers
Recall that in TAXII, recipients SHOULD ignore extended headers they don’t understand (TAXII Services Spec, Section 4.3). The Extended Header field is intended to be an area where specific communities can add functionality to TAXII without having to go outside the spec (think HTTP/SMTP X-Headers).
 
As for a concrete example, I’ll use a feature that was not in TAXII 1.0 and was added to TAXII 1.1: Destination Collection Name. Inbox Messages in TAXII 1.0 did not contain any mechanism for communicating that the content contained in the Inbox Message was destined for a particular Data Collection. Therefore, implementations could (and a few, very few, did – there were another solution that was more common) use an extended header with a name of “Destination_Collection_Names” and an array of values containing the intended Destination Collections (there’s some history here regarding Collection/Feed, but that’s a tangent for this paragraph). Of course, this functionality depends on both TAXII endpoints to implement and respect the Destination Collection Name extended header. There are not any extended headers that are implemented community-wide today.
 
So, for instance:
<taxii:Extended_Headers>
   <taxii:Extended_Header name=”destination_collection_name”>name1</taxii:Extended_Header>
   <taxii:Extended_Header name=”destination_collection_name”>name2</taxii:Extended_Header>
</taxii:Extended_Headers>
 
Thank you. Comments and thoughts are welcome.
-Mark
 
From: Jordan, Bret [[hidden email]] 
Sent: Monday, March 23, 2015 7:02 PM
To: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: [TAXII] JSON Message Binding Specification for TAXII v0.3
 
All,
 
Here is version v0.3 that includes TAXII messages up through 3.7, the Managed Collection Subscription Response.  As a side note, I should be finished with the first full draft by end of week.  Please review and give comments, feedback, suggestions, etc.. 
 
A few points in regards to the JSON style used in this spec.
 
1) I tried to follow the XML field names as close as possible, albeit they are all lower case instead of some fields being first character upper and others being all lower case (this is what I am proposing for JSON STIX in the JSON working group).  I figured by doing this, it would be super easy to process the field names through a to_lc() method.  
 
2) Because of the choice to follow the XML field names, some field names seem long and overly verbose.  I hope that in a future version we can greatly reduce some of these and clean it up a bit.  So unless there is over-whelming feedback to do it now, I will stay lock-n-step with XML for this first version.
 
3) Some of the object structure in XML seem redundant and appears to me that it could be simplified.  I will propose changes and options after this spec is ratified.  
 
4) In general I have chosen to go with arrays of objects instead of just objects or just arrays in a lot of places. This more accurately follows the XML and allows for various other things.  Please see my other posts to understand the details of why I went this way..  I know this is not ideal, but lets get this first version done and approved, then we can start looking at how to make things cleaner and more efficient.  
 
I hope that we can get this spec approved and ratified quickly and get tooling support for it in the next month or so.  This will then give organizations a choice for TAXII, either TAXII XML Messages or TAXII JSON Messages.  And yes, you can stick XML STIX inside of a TAXII JSON Message until we get the JSON STIX stuff done (which is a different animal).


signature.asc (858 bytes) Download Attachment