[TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback

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

[TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback

Jordan, Bret
All,

Here is the final draft of the JSON Binding Spec for TAXII 1.1, version 0.9.  Please submit all comments, feedback, changes, additions, etc, to me by end-of-day Friday April 10, 2015.  

In this version I have incorporated all suggestions and feedback and have tried to follow the TAXII Services Specification as closely as possible.  The one notable exception, as previously discussed on this list, is I have elided the content_binding as there is an existing item in Github to remove it from the Services Specification.  

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.9.pdf (309K) Download Attachment
signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback

Jordan, Bret
I just noticed an issue, in section 3.6 I had the wrong indention for push_parameters.  This will be fixed in the final version.  


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 Apr 6, 2015, at 11:23 AM, Jordan, Bret <[hidden email]> wrote:

All,

Here is the final draft of the JSON Binding Spec for TAXII 1.1, version 0.9.  Please submit all comments, feedback, changes, additions, etc, to me by end-of-day Friday April 10, 2015.  

In this version I have incorporated all suggestions and feedback and have tried to follow the TAXII Services Specification as closely as possible.  The one notable exception, as previously discussed on this list, is I have elided the content_binding as there is an existing item in Github to remove it from the Services Specification.  

Thanks,

Bret
<TAXII_JSON_Message_Binding_Specification_v0.9.pdf>


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." 



signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback

mdavidson
In reply to this post by Jordan, Bret

Bret,

 

I have a quick comment on removing the content_binding removal. While the Content Binding concept may change in a future version of TAXII (as is specified in the tracker item you reference), it seems premature for a TAXII 1.1 Message Binding to incorporate changes that have not yet been made in the TAXII Services Spec.

 

I also see there are signature fields which are implemented as either a string or an array of strings (I’m presuming “one string per signature”), but I don’t see any discussion of how signatures are to be used, implemented, or verified. There should be some indication of how signatures should be handled. Otherwise, how will two implementers have compatible signature implementations based on the spec?

 

Thank you.

-Mark

 

From: Jordan, Bret [mailto:[hidden email]]
Sent: Monday, April 06, 2015 1:24 PM
To: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback

 

All,

 

Here is the final draft of the JSON Binding Spec for TAXII 1.1, version 0.9.  Please submit all comments, feedback, changes, additions, etc, to me by end-of-day Friday April 10, 2015.  

 

In this version I have incorporated all suggestions and feedback and have tried to follow the TAXII Services Specification as closely as possible.  The one notable exception, as previously discussed on this list, is I have elided the content_binding as there is an existing item in Github to remove it from the Services Specification.  

 

Thanks,

 

Bret

Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback

Jordan, Bret
I have been thinking about the signature stuff, and I think I am going to propose in my final document that the signature be moved to the JSON package level.  This will make it super easy, in code, to run and verify the signature.  Thus go from:

{
    "discovery_request": {
        "message_id": "example:dreq-7ffa9ae0-a4f0-411f-82ef-051f0584595e”,
“signature”: “some signatures"
    }
}

TO:

{
    "discovery_request": {
        "message_id": "example:dreq-7ffa9ae0-a4f0-411f-82ef-051f0584595e”
    },
        “signature”: “some signatures"
}

With this change you could easily compute the signature for the discovery_request object in memory.  And on the receiving side, it would be a lot easier to computer the verification.  


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 Apr 7, 2015, at 6:40 AM, Davidson II, Mark S <[hidden email]> wrote:

Bret,
 
I have a quick comment on removing the content_binding removal. While the Content Binding concept may change in a future version of TAXII (as is specified in the tracker item you reference), it seems premature for a TAXII 1.1 Message Binding to incorporate changes that have not yet been made in the TAXII Services Spec.
 
I also see there are signature fields which are implemented as either a string or an array of strings (I’m presuming “one string per signature”), but I don’t see any discussion of how signatures are to be used, implemented, or verified. There should be some indication of how signatures should be handled. Otherwise, how will two implementers have compatible signature implementations based on the spec?
 
Thank you.
-Mark
 
From: Jordan, Bret [[hidden email]] 
Sent: Monday, April 06, 2015 1:24 PM
To: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback
 
All,
 
Here is the final draft of the JSON Binding Spec for TAXII 1.1, version 0.9.  Please submit all comments, feedback, changes, additions, etc, to me by end-of-day Friday April 10, 2015.  
 
In this version I have incorporated all suggestions and feedback and have tried to follow the TAXII Services Specification as closely as possible.  The one notable exception, as previously discussed on this list, is I have elided the content_binding as there is an existing item in Github to remove it from the Services Specification.  
 
Thanks,
 
Bret


signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback

mdavidson

Bret,

 

A problem you’ll run into from the signature standpoint is that the following representations are semantically equivalent (aka mean the same thing) and syntactically different (aka look different):

1) {"message_id": "example:dreq-7ffa9ae0-a4f0-411f-82ef-051f0584595e”}

 

2) {

        "message_id": "example:dreq-7ffa9ae0-a4f0-411f-82ef-051f0584595e”

    }

 

Computing the signature from the JSON object is fine and dandy as long as implementers can “start” from the same representation. The two examples, while equivalent, will have different signatures. XMLDSIG has addressed this with canonicalization.

 

IMO, if signatures are an unsolved problem (I’m not sure whether JSON signatures are solved or unsolved), it’s better to leave it out and add signatures in a future revision than it is to put in a known “unsolved” problem into a document with an attempt to fix it later.

 

Sorry to be a bit of a wet blanket on this topic – signatures as a component of a data representation are hard to solve. Perhaps looking at signatures as a separate layer (e.g., S/MIME) would be a workable approach?

 

Thank you.

-Mark

 

From: Jordan, Bret [mailto:[hidden email]]
Sent: Tuesday, April 07, 2015 2:07 PM
To: Davidson II, Mark S
Cc: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: Re: TAXII JSON Binding Spec v0.9 - last call for feedback

 

I have been thinking about the signature stuff, and I think I am going to propose in my final document that the signature be moved to the JSON package level.  This will make it super easy, in code, to run and verify the signature.  Thus go from:

 

{

    "discovery_request": {

        "message_id": "example:dreq-7ffa9ae0-a4f0-411f-82ef-051f0584595e”,

     “signature”: “some signatures"

    }

}

 

TO:

 

{

    "discovery_request": {

        "message_id": "example:dreq-7ffa9ae0-a4f0-411f-82ef-051f0584595e”

    },

        “signature”: “some signatures"

}

 

With this change you could easily compute the signature for the discovery_request object in memory.  And on the receiving side, it would be a lot easier to computer the verification.  

 

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 Apr 7, 2015, at 6:40 AM, Davidson II, Mark S <[hidden email]> wrote:

 

Bret,

 

I have a quick comment on removing the content_binding removal. While the Content Binding concept may change in a future version of TAXII (as is specified in the tracker item you reference), it seems premature for a TAXII 1.1 Message Binding to incorporate changes that have not yet been made in the TAXII Services Spec.

 

I also see there are signature fields which are implemented as either a string or an array of strings (I’m presuming “one string per signature”), but I don’t see any discussion of how signatures are to be used, implemented, or verified. There should be some indication of how signatures should be handled. Otherwise, how will two implementers have compatible signature implementations based on the spec?

 

Thank you.

-Mark

 

From: Jordan, Bret [[hidden email]] 
Sent: Monday, April 06, 2015 1:24 PM
To: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback

 

All,

 

Here is the final draft of the JSON Binding Spec for TAXII 1.1, version 0.9.  Please submit all comments, feedback, changes, additions, etc, to me by end-of-day Friday April 10, 2015.  

 

In this version I have incorporated all suggestions and feedback and have tried to follow the TAXII Services Specification as closely as possible.  The one notable exception, as previously discussed on this list, is I have elided the content_binding as there is an existing item in Github to remove it from the Services Specification.  

 

Thanks,

 

Bret

 

Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback

Jordan, Bret
Very interesting and good comments…  

My view is that you would unmarshal the JSON into your objects in memory, thus getting rid of all of the spacing and indentation.   You would then run a signature on that object in memory.  

Now to your point, this may even still very between different versions of JSON libraries.  Would need to look at that and run some tests.

I will do another lit review of JSON based signatures and will do one of the following:

1) Revise the document based on what is a standard JSON signature 
2) Pull the signatures out of this version, with the idea they will be added back in with a future version.



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 Apr 7, 2015, at 1:13 PM, Davidson II, Mark S <[hidden email]> wrote:

Bret,
 
A problem you’ll run into from the signature standpoint is that the following representations are semantically equivalent (aka mean the same thing) and syntactically different (aka look different):
1) {"message_id": "example:dreq-7ffa9ae0-a4f0-411f-82ef-051f0584595e”}
 
2) {
        "message_id": "example:dreq-7ffa9ae0-a4f0-411f-82ef-051f0584595e”
    }
 
Computing the signature from the JSON object is fine and dandy as long as implementers can “start” from the same representation. The two examples, while equivalent, will have different signatures. XMLDSIG has addressed this with canonicalization.
 
IMO, if signatures are an unsolved problem (I’m not sure whether JSON signatures are solved or unsolved), it’s better to leave it out and add signatures in a future revision than it is to put in a known “unsolved” problem into a document with an attempt to fix it later.
 
Sorry to be a bit of a wet blanket on this topic – signatures as a component of a data representation are hard to solve. Perhaps looking at signatures as a separate layer (e.g., S/MIME) would be a workable approach?
 
Thank you.
-Mark
 
From: Jordan, Bret [[hidden email]] 
Sent: Tuesday, April 07, 2015 2:07 PM
To: Davidson II, Mark S
Cc: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: Re: TAXII JSON Binding Spec v0.9 - last call for feedback
 
I have been thinking about the signature stuff, and I think I am going to propose in my final document that the signature be moved to the JSON package level.  This will make it super easy, in code, to run and verify the signature.  Thus go from:
 
{
    "discovery_request": {
        "message_id": "example:dreq-7ffa9ae0-a4f0-411f-82ef-051f0584595e”,
     “signature”: “some signatures"
    }
}
 
TO:
 
{
    "discovery_request": {
        "message_id": "example:dreq-7ffa9ae0-a4f0-411f-82ef-051f0584595e”
    },
        “signature”: “some signatures"
}
 
With this change you could easily compute the signature for the discovery_request object in memory.  And on the receiving side, it would be a lot easier to computer the verification.  

 

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 Apr 7, 2015, at 6:40 AM, Davidson II, Mark S <[hidden email]> wrote:
 
Bret,
 
I have a quick comment on removing the content_binding removal. While the Content Binding concept may change in a future version of TAXII (as is specified in the tracker item you reference), it seems premature for a TAXII 1.1 Message Binding to incorporate changes that have not yet been made in the TAXII Services Spec.
 
I also see there are signature fields which are implemented as either a string or an array of strings (I’m presuming “one string per signature”), but I don’t see any discussion of how signatures are to be used, implemented, or verified. There should be some indication of how signatures should be handled. Otherwise, how will two implementers have compatible signature implementations based on the spec?
 
Thank you.
-Mark
 
From: Jordan, Bret [[hidden email]] 
Sent: Monday, April 06, 2015 1:24 PM
To: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback
 
All,
 
Here is the final draft of the JSON Binding Spec for TAXII 1.1, version 0.9.  Please submit all comments, feedback, changes, additions, etc, to me by end-of-day Friday April 10, 2015.  
 
In this version I have incorporated all suggestions and feedback and have tried to follow the TAXII Services Specification as closely as possible.  The one notable exception, as previously discussed on this list, is I have elided the content_binding as there is an existing item in Github to remove it from the Services Specification.  
 
Thanks,
 
Bret


signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback

Jordan, Bret
It looks like there is stuff coming out of the IETF for this, called JSW [1].  Given that, I think I will pull signatures for now, with the idea that we will add them back in with a 1.1 release.  Doing this will allow people interested in JSON to start work on the main constructs and get things going.  Then we can add JSON based signatures later in a backwards compatible way. If we do it now, and have to radically change it later, we would have a breaking change which would not be good.

[1] https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41


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 Apr 7, 2015, at 1:18 PM, Jordan, Bret <[hidden email]> wrote:

Very interesting and good comments…  

My view is that you would unmarshal the JSON into your objects in memory, thus getting rid of all of the spacing and indentation.   You would then run a signature on that object in memory.  

Now to your point, this may even still very between different versions of JSON libraries.  Would need to look at that and run some tests.

I will do another lit review of JSON based signatures and will do one of the following:

1) Revise the document based on what is a standard JSON signature 
2) Pull the signatures out of this version, with the idea they will be added back in with a future version.



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 Apr 7, 2015, at 1:13 PM, Davidson II, Mark S <[hidden email]> wrote:

Bret,
 
A problem you’ll run into from the signature standpoint is that the following representations are semantically equivalent (aka mean the same thing) and syntactically different (aka look different):
1) {"message_id": "example:dreq-7ffa9ae0-a4f0-411f-82ef-051f0584595e”}
 
2) {
        "message_id": "example:dreq-7ffa9ae0-a4f0-411f-82ef-051f0584595e”
    }
 
Computing the signature from the JSON object is fine and dandy as long as implementers can “start” from the same representation. The two examples, while equivalent, will have different signatures. XMLDSIG has addressed this with canonicalization.
 
IMO, if signatures are an unsolved problem (I’m not sure whether JSON signatures are solved or unsolved), it’s better to leave it out and add signatures in a future revision than it is to put in a known “unsolved” problem into a document with an attempt to fix it later.
 
Sorry to be a bit of a wet blanket on this topic – signatures as a component of a data representation are hard to solve. Perhaps looking at signatures as a separate layer (e.g., S/MIME) would be a workable approach?
 
Thank you.
-Mark
 
From: Jordan, Bret [[hidden email]] 
Sent: Tuesday, April 07, 2015 2:07 PM
To: Davidson II, Mark S
Cc: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: Re: TAXII JSON Binding Spec v0.9 - last call for feedback
 
I have been thinking about the signature stuff, and I think I am going to propose in my final document that the signature be moved to the JSON package level.  This will make it super easy, in code, to run and verify the signature.  Thus go from:
 
{
    "discovery_request": {
        "message_id": "example:dreq-7ffa9ae0-a4f0-411f-82ef-051f0584595e”,
     “signature”: “some signatures"
    }
}
 
TO:
 
{
    "discovery_request": {
        "message_id": "example:dreq-7ffa9ae0-a4f0-411f-82ef-051f0584595e”
    },
        “signature”: “some signatures"
}
 
With this change you could easily compute the signature for the discovery_request object in memory.  And on the receiving side, it would be a lot easier to computer the verification.  
 
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 Apr 7, 2015, at 6:40 AM, Davidson II, Mark S <[hidden email]> wrote:
 
Bret,
 
I have a quick comment on removing the content_binding removal. While the Content Binding concept may change in a future version of TAXII (as is specified in the tracker item you reference), it seems premature for a TAXII 1.1 Message Binding to incorporate changes that have not yet been made in the TAXII Services Spec.
 
I also see there are signature fields which are implemented as either a string or an array of strings (I’m presuming “one string per signature”), but I don’t see any discussion of how signatures are to be used, implemented, or verified. There should be some indication of how signatures should be handled. Otherwise, how will two implementers have compatible signature implementations based on the spec?
 
Thank you.
-Mark
 
From: Jordan, Bret [[hidden email]] 
Sent: Monday, April 06, 2015 1:24 PM
To: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback
 
All,
 
Here is the final draft of the JSON Binding Spec for TAXII 1.1, version 0.9.  Please submit all comments, feedback, changes, additions, etc, to me by end-of-day Friday April 10, 2015.  
 
In this version I have incorporated all suggestions and feedback and have tried to follow the TAXII Services Specification as closely as possible.  The one notable exception, as previously discussed on this list, is I have elided the content_binding as there is an existing item in Github to remove it from the Services Specification.  
 
Thanks,
 
Bret



signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback

Terry MacDonald
Good call I think.

Cheers
Terry MacDonald


On 8 April 2015 at 05:38, Jordan, Bret <[hidden email]> wrote:
It looks like there is stuff coming out of the IETF for this, called JSW [1].  Given that, I think I will pull signatures for now, with the idea that we will add them back in with a 1.1 release.  Doing this will allow people interested in JSON to start work on the main constructs and get things going.  Then we can add JSON based signatures later in a backwards compatible way. If we do it now, and have to radically change it later, we would have a breaking change which would not be good.

[1] https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41


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 Apr 7, 2015, at 1:18 PM, Jordan, Bret <[hidden email]> wrote:

Very interesting and good comments…  

My view is that you would unmarshal the JSON into your objects in memory, thus getting rid of all of the spacing and indentation.   You would then run a signature on that object in memory.  

Now to your point, this may even still very between different versions of JSON libraries.  Would need to look at that and run some tests.

I will do another lit review of JSON based signatures and will do one of the following:

1) Revise the document based on what is a standard JSON signature 
2) Pull the signatures out of this version, with the idea they will be added back in with a future version.



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 Apr 7, 2015, at 1:13 PM, Davidson II, Mark S <[hidden email]> wrote:

Bret,
 
A problem you’ll run into from the signature standpoint is that the following representations are semantically equivalent (aka mean the same thing) and syntactically different (aka look different):
1) {"message_id": "example:dreq-7ffa9ae0-a4f0-411f-82ef-051f0584595e”}
 
2) {
        "message_id": "example:dreq-7ffa9ae0-a4f0-411f-82ef-051f0584595e”
    }
 
Computing the signature from the JSON object is fine and dandy as long as implementers can “start” from the same representation. The two examples, while equivalent, will have different signatures. XMLDSIG has addressed this with canonicalization.
 
IMO, if signatures are an unsolved problem (I’m not sure whether JSON signatures are solved or unsolved), it’s better to leave it out and add signatures in a future revision than it is to put in a known “unsolved” problem into a document with an attempt to fix it later.
 
Sorry to be a bit of a wet blanket on this topic – signatures as a component of a data representation are hard to solve. Perhaps looking at signatures as a separate layer (e.g., S/MIME) would be a workable approach?
 
Thank you.
-Mark
 
From: Jordan, Bret [[hidden email]] 
Sent: Tuesday, April 07, 2015 2:07 PM
To: Davidson II, Mark S
Cc: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: Re: TAXII JSON Binding Spec v0.9 - last call for feedback
 
I have been thinking about the signature stuff, and I think I am going to propose in my final document that the signature be moved to the JSON package level.  This will make it super easy, in code, to run and verify the signature.  Thus go from:
 
{
    "discovery_request": {
        "message_id": "example:dreq-7ffa9ae0-a4f0-411f-82ef-051f0584595e”,
     “signature”: “some signatures"
    }
}
 
TO:
 
{
    "discovery_request": {
        "message_id": "example:dreq-7ffa9ae0-a4f0-411f-82ef-051f0584595e”
    },
        “signature”: “some signatures"
}
 
With this change you could easily compute the signature for the discovery_request object in memory.  And on the receiving side, it would be a lot easier to computer the verification.  
 
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 Apr 7, 2015, at 6:40 AM, Davidson II, Mark S <[hidden email]> wrote:
 
Bret,
 
I have a quick comment on removing the content_binding removal. While the Content Binding concept may change in a future version of TAXII (as is specified in the tracker item you reference), it seems premature for a TAXII 1.1 Message Binding to incorporate changes that have not yet been made in the TAXII Services Spec.
 
I also see there are signature fields which are implemented as either a string or an array of strings (I’m presuming “one string per signature”), but I don’t see any discussion of how signatures are to be used, implemented, or verified. There should be some indication of how signatures should be handled. Otherwise, how will two implementers have compatible signature implementations based on the spec?
 
Thank you.
-Mark
 
From: Jordan, Bret [[hidden email]] 
Sent: Monday, April 06, 2015 1:24 PM
To: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback
 
All,
 
Here is the final draft of the JSON Binding Spec for TAXII 1.1, version 0.9.  Please submit all comments, feedback, changes, additions, etc, to me by end-of-day Friday April 10, 2015.  
 
In this version I have incorporated all suggestions and feedback and have tried to follow the TAXII Services Specification as closely as possible.  The one notable exception, as previously discussed on this list, is I have elided the content_binding as there is an existing item in Github to remove it from the Services Specification.  
 
Thanks,
 
Bret



Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback

Sergey Polzunov
In reply to this post by Jordan, Bret
Bret,

Great job on the draft! I’ve aligned JSON schemas with version 0.9, please take a look.

I have a few comments/questions:

- The values of MAX_PART_NUMBER and ESTIMATED_WAIT should be marked as “number” and not “string"? That would allow a validation on schema level (example - https://github.com/traut/taxii-json-schemas-draft/blob/master/schemas/message.json#L17);
- maybe we can rename “allow_asynch" to “allow_async”. “asynch” spelling is really unusual;
- why every content block has an array of signatures? isn’t it just one? “signature” (singular?) fields in Table 3.9-1 and Table 3.10-1 are marked as “array”.

Small issues:

- Table 3.1-3 contains ESTIMATED_WAIT 2 times
- Table 3.7-1
        - “message_bindings” in “push_parameters” are marked as “string”, should be “array"
        - “poll_instances” marked as “object”, should be “array"
- TABLE 3.10-1 “destination_collection_name” should be plural “destination_collection_names”.
- TABLE 3.11-1 “result_part_number” should be described as “positive non-zero integer”, because it starts with 1


Sergey Polzunov
Intelworks



> On 06 Apr 2015, at 20:12, Jordan, Bret <[hidden email]> wrote:
>
> I just noticed an issue, in section 3.6 I had the wrong indention for push_parameters.  This will be fixed in the final version.  
>
>
> 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 Apr 6, 2015, at 11:23 AM, Jordan, Bret <[hidden email]> wrote:
>>
>> All,
>>
>> Here is the final draft of the JSON Binding Spec for TAXII 1.1, version 0.9.  Please submit all comments, feedback, changes, additions, etc, to me by end-of-day Friday April 10, 2015.  
>>
>> In this version I have incorporated all suggestions and feedback and have tried to follow the TAXII Services Specification as closely as possible.  The one notable exception, as previously discussed on this list, is I have elided the content_binding as there is an existing item in Github to remove it from the Services Specification.  
>>
>> Thanks,
>>
>> Bret
>> <TAXII_JSON_Message_Binding_Specification_v0.9.pdf>
>>
>>
>> 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."
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback

Jordan, Bret
I have made all of these changes, plus lots others from other people, accept the following two..

1) I did not rename alllow_asynch. I agree with you that we should, and we should rename a lot of the other fields that we have talked about in the past.  I just worry that if we do that for this initial version it will deviate too much from the XML version and this will cause concern in the community.  Unless people think it is okay for the JSON version to be that much different from the XML, I think we should try and do a TAXII 2.0 where we can fix a lot of the field names and shorten a lot of the field names.

2) 3-7.1 for Push_Parameters is correct per the XML version.  I know, I really wish it was an Array of Objects and that Message_Bindings was an array.  It would make processing so much easier if they were all the same type of structure.

One thing we COULD do with 3.7-1 is make them the same as the other data structures, meaning make it an Array of Objects and make Message_Bindings and array, but then say only ONE option is valid.   The reason for doing this is then you would only need one function to deal with that type of data…  Let me know what you think about that…  I am kind of liking that approach.  


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 Apr 9, 2015, at 3:03 AM, Sergey Polzunov <[hidden email]> wrote:

Bret,

Great job on the draft! I’ve aligned JSON schemas with version 0.9, please take a look.

I have a few comments/questions:

- The values of MAX_PART_NUMBER and ESTIMATED_WAIT should be marked as “number” and not “string"? That would allow a validation on schema level (example - https://github.com/traut/taxii-json-schemas-draft/blob/master/schemas/message.json#L17);
- maybe we can rename “allow_asynch" to “allow_async”. “asynch” spelling is really unusual;
- why every content block has an array of signatures? isn’t it just one? “signature” (singular?) fields in Table 3.9-1 and Table 3.10-1 are marked as “array”.

Small issues:

- Table 3.1-3 contains ESTIMATED_WAIT 2 times
- Table 3.7-1
- “message_bindings” in “push_parameters” are marked as “string”, should be “array"
- “poll_instances” marked as “object”, should be “array"
- TABLE 3.10-1 “destination_collection_name” should be plural “destination_collection_names”.
- TABLE 3.11-1 “result_part_number” should be described as “positive non-zero integer”, because it starts with 1


Sergey Polzunov
Intelworks



On 06 Apr 2015, at 20:12, Jordan, Bret <[hidden email]> wrote:

I just noticed an issue, in section 3.6 I had the wrong indention for push_parameters.  This will be fixed in the final version.  


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 Apr 6, 2015, at 11:23 AM, Jordan, Bret <[hidden email]> wrote:

All,

Here is the final draft of the JSON Binding Spec for TAXII 1.1, version 0.9.  Please submit all comments, feedback, changes, additions, etc, to me by end-of-day Friday April 10, 2015.  

In this version I have incorporated all suggestions and feedback and have tried to follow the TAXII Services Specification as closely as possible.  The one notable exception, as previously discussed on this list, is I have elided the content_binding as there is an existing item in Github to remove it from the Services Specification.  

Thanks,

Bret
<TAXII_JSON_Message_Binding_Specification_v0.9.pdf>


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."





signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback

Sergey Polzunov

> 1) I did not rename alllow_asynch. I agree with you that we should, and we should rename a lot of the other fields that we have talked about in the past.  I just worry that if we do that for this initial version it will deviate too much from the XML version and this will cause concern in the community.  Unless people think it is okay for the JSON version to be that much different from the XML, I think we should try and do a TAXII 2.0 where we can fix a lot of the field names and shorten a lot of the field names.

I think it is better to deviate from XML drastically right away than introduce a lot of changes in the next version. We should keep in mind that (hopefully) a lot of new people will start with JSON bindings having no experience with XML bindings at all.

We're already making a jump here (hierarchy is different, field names are different sometimes), might as well go all the way.

> 2) 3-7.1 for Push_Parameters is correct per the XML version.  I know, I really wish it was an Array of Objects and that Message_Bindings was an array.  It would make processing so much easier if they were all the same type of structure.
> One thing we COULD do with 3.7-1 is make them the same as the other data structures, meaning make it an Array of Objects and make Message_Bindings and array, but then say only ONE option is valid.   The reason for doing this is then you would only need one function to deal with that type of data…  Let me know what you think about that…  I am kind of liking that approach.  

I think this is a good idea. This will allow us to use one unified structure not only for validation (in jsonschema, https://github.com/traut/taxii-json-schemas-draft/blob/master/schemas/service-basics.json) but also in the code.

While we at it, can we rename “push_parameters” into “delivery_parameters”? I believe this field is called “Delivery Parameters” in 1.1 and “Push Parameters” is an old name that was somehow dragged into 1.1 XSD files from v1.0.

Thanks,
Sergey Polzunov
Intelworks

>
> 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 Apr 9, 2015, at 3:03 AM, Sergey Polzunov <[hidden email]> wrote:
>>
>> Bret,
>>
>> Great job on the draft! I’ve aligned JSON schemas with version 0.9, please take a look.
>>
>> I have a few comments/questions:
>>
>> - The values of MAX_PART_NUMBER and ESTIMATED_WAIT should be marked as “number” and not “string"? That would allow a validation on schema level (example - https://github.com/traut/taxii-json-schemas-draft/blob/master/schemas/message.json#L17);
>> - maybe we can rename “allow_asynch" to “allow_async”. “asynch” spelling is really unusual;
>> - why every content block has an array of signatures? isn’t it just one? “signature” (singular?) fields in Table 3.9-1 and Table 3.10-1 are marked as “array”.
>>
>> Small issues:
>>
>> - Table 3.1-3 contains ESTIMATED_WAIT 2 times
>> - Table 3.7-1
>> - “message_bindings” in “push_parameters” are marked as “string”, should be “array"
>> - “poll_instances” marked as “object”, should be “array"
>> - TABLE 3.10-1 “destination_collection_name” should be plural “destination_collection_names”.
>> - TABLE 3.11-1 “result_part_number” should be described as “positive non-zero integer”, because it starts with 1
>>
>>
>> Sergey Polzunov
>> Intelworks
>>
>>
>>
>>> On 06 Apr 2015, at 20:12, Jordan, Bret <[hidden email]> wrote:
>>>
>>> I just noticed an issue, in section 3.6 I had the wrong indention for push_parameters.  This will be fixed in the final version.  
>>>
>>>
>>> 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 Apr 6, 2015, at 11:23 AM, Jordan, Bret <[hidden email]> wrote:
>>>>
>>>> All,
>>>>
>>>> Here is the final draft of the JSON Binding Spec for TAXII 1.1, version 0.9.  Please submit all comments, feedback, changes, additions, etc, to me by end-of-day Friday April 10, 2015.  
>>>>
>>>> In this version I have incorporated all suggestions and feedback and have tried to follow the TAXII Services Specification as closely as possible.  The one notable exception, as previously discussed on this list, is I have elided the content_binding as there is an existing item in Github to remove it from the Services Specification.  
>>>>
>>>> Thanks,
>>>>
>>>> Bret
>>>> <TAXII_JSON_Message_Binding_Specification_v0.9.pdf>
>>>>
>>>>
>>>> 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."
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback

Jordan, Bret
So unless anyone else objects, wildly, I will do this..  

Everyone, please submit a laundry list of all of the field names that should be changed / shortened.  I know there is a Github Issue for doing this in XML anyway.  Lets just lead the way with how this should look.  And like you said Sergey, long term, I see people moving to JSON based TAXII anyway.  

If anyone is in violent objection to this, please speak up...


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 Apr 9, 2015, at 9:16 AM, Sergey Polzunov <[hidden email]> wrote:


1) I did not rename alllow_asynch. I agree with you that we should, and we should rename a lot of the other fields that we have talked about in the past.  I just worry that if we do that for this initial version it will deviate too much from the XML version and this will cause concern in the community.  Unless people think it is okay for the JSON version to be that much different from the XML, I think we should try and do a TAXII 2.0 where we can fix a lot of the field names and shorten a lot of the field names.

I think it is better to deviate from XML drastically right away than introduce a lot of changes in the next version. We should keep in mind that (hopefully) a lot of new people will start with JSON bindings having no experience with XML bindings at all.

We're already making a jump here (hierarchy is different, field names are different sometimes), might as well go all the way.

2) 3-7.1 for Push_Parameters is correct per the XML version.  I know, I really wish it was an Array of Objects and that Message_Bindings was an array.  It would make processing so much easier if they were all the same type of structure.
One thing we COULD do with 3.7-1 is make them the same as the other data structures, meaning make it an Array of Objects and make Message_Bindings and array, but then say only ONE option is valid.   The reason for doing this is then you would only need one function to deal with that type of data…  Let me know what you think about that…  I am kind of liking that approach.  

I think this is a good idea. This will allow us to use one unified structure not only for validation (in jsonschema, https://github.com/traut/taxii-json-schemas-draft/blob/master/schemas/service-basics.json) but also in the code.

While we at it, can we rename “push_parameters” into “delivery_parameters”? I believe this field is called “Delivery Parameters” in 1.1 and “Push Parameters” is an old name that was somehow dragged into 1.1 XSD files from v1.0.

Thanks,
Sergey Polzunov
Intelworks


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 Apr 9, 2015, at 3:03 AM, Sergey Polzunov <[hidden email]> wrote:

Bret,

Great job on the draft! I’ve aligned JSON schemas with version 0.9, please take a look.

I have a few comments/questions:

- The values of MAX_PART_NUMBER and ESTIMATED_WAIT should be marked as “number” and not “string"? That would allow a validation on schema level (example - https://github.com/traut/taxii-json-schemas-draft/blob/master/schemas/message.json#L17);
- maybe we can rename “allow_asynch" to “allow_async”. “asynch” spelling is really unusual;
- why every content block has an array of signatures? isn’t it just one? “signature” (singular?) fields in Table 3.9-1 and Table 3.10-1 are marked as “array”.

Small issues:

- Table 3.1-3 contains ESTIMATED_WAIT 2 times
- Table 3.7-1
- “message_bindings” in “push_parameters” are marked as “string”, should be “array"
- “poll_instances” marked as “object”, should be “array"
- TABLE 3.10-1 “destination_collection_name” should be plural “destination_collection_names”.
- TABLE 3.11-1 “result_part_number” should be described as “positive non-zero integer”, because it starts with 1


Sergey Polzunov
Intelworks



On 06 Apr 2015, at 20:12, Jordan, Bret <[hidden email]> wrote:

I just noticed an issue, in section 3.6 I had the wrong indention for push_parameters.  This will be fixed in the final version.  


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 Apr 6, 2015, at 11:23 AM, Jordan, Bret <[hidden email]> wrote:

All,

Here is the final draft of the JSON Binding Spec for TAXII 1.1, version 0.9.  Please submit all comments, feedback, changes, additions, etc, to me by end-of-day Friday April 10, 2015.  

In this version I have incorporated all suggestions and feedback and have tried to follow the TAXII Services Specification as closely as possible.  The one notable exception, as previously discussed on this list, is I have elided the content_binding as there is an existing item in Github to remove it from the Services Specification.  

Thanks,

Bret
<TAXII_JSON_Message_Binding_Specification_v0.9.pdf>


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."







signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback

Jordan, Bret
Here is my list of proposed field name changes for the JSON Message Binding for TAXII, my wish list… :)

Status Message Type
message_id  -> id
status_type -> type
status_details -> details

Discovery Request Type
message_id  -> id

Discovery Response Type
message_id  -> id
service_instances -> services
service_type  -> type
service_version -> version
protocol_binding -> protocol
message_binding -> ??

Collection Information Request Type
message_id  -> id

Collection Information Response Type
message_id  -> id
collection_name  -> name
collection_type  -> type
collection_volume -> volume
protocol_binding -> protocol
message_binding -> ??
push_methods  -> push_services (so it fits with the others)
receiving_inbox_services -> inbox_services

Managed Collection Subscription Request Type
message_id  -> id
collection_name  -> name
push_parameters  -> push_services
protocol_binding -> protocol
message_binding -> ??

Managed Collection Subscription Response Type
message_id  -> id
collection_name  -> name
push_parameters  -> push_services
poll_instances -> poll_services
protocol_binding -> protocol
message_binding -> ??

Poll Request Type
message_id  -> id
collection_name  -> name
delivery_parameters -> inbox_services
protocol_binding -> protocol
message_binding -> ??

Poll Response Type
message_id  -> id
collection_name  -> name

Inbox Message Type
message_id  -> id
collection_name  -> name

Fulfillment Request Type
message_id  -> id
collection_name  -> name


And my super super big wish item, that I do not think I will ever get, is we could change Poll to Pull or better yet Get.


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." 



signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback

Jordan, Bret
maybe change message_bindings -> encoding 


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 Apr 9, 2015, at 12:06 PM, Jordan, Bret <[hidden email]> wrote:

Here is my list of proposed field name changes for the JSON Message Binding for TAXII, my wish list… :)

Status Message Type
message_id  -> id
status_type -> type
status_details -> details

Discovery Request Type
message_id  -> id

Discovery Response Type
message_id  -> id
service_instances -> services
service_type  -> type
service_version -> version
protocol_binding -> protocol
message_binding -> ??

Collection Information Request Type
message_id  -> id

Collection Information Response Type
message_id  -> id
collection_name  -> name
collection_type  -> type
collection_volume -> volume
protocol_binding -> protocol
message_binding -> ??
push_methods  -> push_services (so it fits with the others)
receiving_inbox_services -> inbox_services

Managed Collection Subscription Request Type
message_id  -> id
collection_name  -> name
push_parameters  -> push_services
protocol_binding -> protocol
message_binding -> ??

Managed Collection Subscription Response Type
message_id  -> id
collection_name  -> name
push_parameters  -> push_services
poll_instances -> poll_services
protocol_binding -> protocol
message_binding -> ??

Poll Request Type
message_id  -> id
collection_name  -> name
delivery_parameters -> inbox_services
protocol_binding -> protocol
message_binding -> ??

Poll Response Type
message_id  -> id
collection_name  -> name

Inbox Message Type
message_id  -> id
collection_name  -> name

Fulfillment Request Type
message_id  -> id
collection_name  -> name


And my super super big wish item, that I do not think I will ever get, is we could change Poll to Pull or better yet Get.


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." 




signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

[TAXII] JSON Binding Spec v0.95 - some field name changes

Jordan, Bret
Here is a version that reflects the field name changes we have been talking about.  I have not updated Section 4 to reflect the changes yet, wanted to get everyone’s feedback first. 





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.95.pdf (306K) Download Attachment
signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback

Sergey Polzunov
In reply to this post by Jordan, Bret
Awesome! I’m all for the change.

Some comments:

- “message_binding” can be just “format”, but I’m ok with leaving it as is

- using “push_services” instead of “push_methods” may be confusing. I would leave it as is.
“Push Methods” field defines what protocols/message bindings TAXII server supports for pushing data. These are not properties of the service (there is no address in Push Methods), so having “_services” suffix there will be misleading. Compare https://github.com/traut/taxii-json-schemas-draft/blob/master/schemas/service-basics.json and https://github.com/traut/taxii-json-schemas-draft/blob/master/schemas/service-instance-basics.json

- “push_services” instead of “push_parameters” is also confusing. This field does not define a service that “pushes”, it defines the receiving service. I would suggest “receiving_inbox_service” or similar. Otherwise, keeping “push_parameters” as is is also fine.

- I would keep “collection_name” field as is on the root level (everywhere except in "Collection Information Response”). On the root level I find “name” too generic and too confusing.

I see a danger here though: if we deviate too far from original TAXII Spec, and TAXII 2.0 introduces new fields or better names, users may need a glossary to translate TAXII entities into JSON binding entities. We need to find a middle ground here.

Thanks,
Sergey Polzunov
Intelworks



> On 09 Apr 2015, at 20:28, Jordan, Bret <[hidden email]> wrote:
>
> maybe change message_bindings -> encoding
>
>
> 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 Apr 9, 2015, at 12:06 PM, Jordan, Bret <[hidden email]> wrote:
>>
>> Here is my list of proposed field name changes for the JSON Message Binding for TAXII, my wish list… :)
>>
>> Status Message Type
>> message_id -> id
>> status_type -> type
>> status_details -> details
>>
>> Discovery Request Type
>> message_id -> id
>>
>> Discovery Response Type
>> message_id -> id
>> service_instances -> services
>> service_type -> type
>> service_version -> version
>> protocol_binding -> protocol
>> message_binding -> ??
>>
>> Collection Information Request Type
>> message_id -> id
>>
>> Collection Information Response Type
>> message_id -> id
>> collection_name -> name
>> collection_type -> type
>> collection_volume -> volume
>> protocol_binding -> protocol
>> message_binding -> ??
>> push_methods -> push_services (so it fits with the others)
>> receiving_inbox_services -> inbox_services
>>
>> Managed Collection Subscription Request Type
>> message_id -> id
>> collection_name -> name
>> push_parameters -> push_services
>> protocol_binding -> protocol
>> message_binding -> ??
>>
>> Managed Collection Subscription Response Type
>> message_id -> id
>> collection_name -> name
>> push_parameters -> push_services
>> poll_instances -> poll_services
>> protocol_binding -> protocol
>> message_binding -> ??
>>
>> Poll Request Type
>> message_id -> id
>> collection_name -> name
>> delivery_parameters -> inbox_services
>> protocol_binding -> protocol
>> message_binding -> ??
>>
>> Poll Response Type
>> message_id -> id
>> collection_name -> name
>>
>> Inbox Message Type
>> message_id -> id
>> collection_name -> name
>>
>> Fulfillment Request Type
>> message_id -> id
>> collection_name -> name
>>
>>
>> And my super super big wish item, that I do not think I will ever get, is we could change Poll to Pull or better yet Get.
>>
>>
>> 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."
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback

Jordan, Bret
Very good points!!!  I back out most of those stretch changes…  I will send out a new version shortly.


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 Apr 9, 2015, at 1:18 PM, Sergey Polzunov <[hidden email]> wrote:

Awesome! I’m all for the change.

Some comments:

- “message_binding” can be just “format”, but I’m ok with leaving it as is

- using “push_services” instead of “push_methods” may be confusing. I would leave it as is.
“Push Methods” field defines what protocols/message bindings TAXII server supports for pushing data. These are not properties of the service (there is no address in Push Methods), so having “_services” suffix there will be misleading. Compare https://github.com/traut/taxii-json-schemas-draft/blob/master/schemas/service-basics.json and https://github.com/traut/taxii-json-schemas-draft/blob/master/schemas/service-instance-basics.json

- “push_services” instead of “push_parameters” is also confusing. This field does not define a service that “pushes”, it defines the receiving service. I would suggest “receiving_inbox_service” or similar. Otherwise, keeping “push_parameters” as is is also fine.

- I would keep “collection_name” field as is on the root level (everywhere except in "Collection Information Response”). On the root level I find “name” too generic and too confusing.

I see a danger here though: if we deviate too far from original TAXII Spec, and TAXII 2.0 introduces new fields or better names, users may need a glossary to translate TAXII entities into JSON binding entities. We need to find a middle ground here.

Thanks,
Sergey Polzunov
Intelworks



On 09 Apr 2015, at 20:28, Jordan, Bret <[hidden email]> wrote:

maybe change message_bindings -> encoding


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 Apr 9, 2015, at 12:06 PM, Jordan, Bret <[hidden email]> wrote:

Here is my list of proposed field name changes for the JSON Message Binding for TAXII, my wish list… :)

Status Message Type
message_id -> id
status_type -> type
status_details -> details

Discovery Request Type
message_id -> id

Discovery Response Type
message_id -> id
service_instances -> services
service_type -> type
service_version -> version
protocol_binding -> protocol
message_binding -> ??

Collection Information Request Type
message_id -> id

Collection Information Response Type
message_id -> id
collection_name -> name
collection_type -> type
collection_volume -> volume
protocol_binding -> protocol
message_binding -> ??
push_methods -> push_services (so it fits with the others)
receiving_inbox_services -> inbox_services

Managed Collection Subscription Request Type
message_id -> id
collection_name -> name
push_parameters -> push_services
protocol_binding -> protocol
message_binding -> ??

Managed Collection Subscription Response Type
message_id -> id
collection_name -> name
push_parameters -> push_services
poll_instances -> poll_services
protocol_binding -> protocol
message_binding -> ??

Poll Request Type
message_id -> id
collection_name -> name
delivery_parameters -> inbox_services
protocol_binding -> protocol
message_binding -> ??

Poll Response Type
message_id -> id
collection_name -> name

Inbox Message Type
message_id -> id
collection_name -> name

Fulfillment Request Type
message_id -> id
collection_name -> name


And my super super big wish item, that I do not think I will ever get, is we could change Poll to Pull or better yet Get.


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."






signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII JSON Binding Spec v0.9 - last call for feedback

Jordan, Bret
This version has been fully updated, including section 4, with the proposed changes to field names.  I backed out all of the ones you called out.



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 Apr 9, 2015, at 2:36 PM, Jordan, Bret <[hidden email]> wrote:

Very good points!!!  I back out most of those stretch changes…  I will send out a new version shortly.


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 Apr 9, 2015, at 1:18 PM, Sergey Polzunov <[hidden email]> wrote:

Awesome! I’m all for the change.

Some comments:

- “message_binding” can be just “format”, but I’m ok with leaving it as is

- using “push_services” instead of “push_methods” may be confusing. I would leave it as is.
“Push Methods” field defines what protocols/message bindings TAXII server supports for pushing data. These are not properties of the service (there is no address in Push Methods), so having “_services” suffix there will be misleading. Compare https://github.com/traut/taxii-json-schemas-draft/blob/master/schemas/service-basics.json and https://github.com/traut/taxii-json-schemas-draft/blob/master/schemas/service-instance-basics.json

- “push_services” instead of “push_parameters” is also confusing. This field does not define a service that “pushes”, it defines the receiving service. I would suggest “receiving_inbox_service” or similar. Otherwise, keeping “push_parameters” as is is also fine.

- I would keep “collection_name” field as is on the root level (everywhere except in "Collection Information Response”). On the root level I find “name” too generic and too confusing.

I see a danger here though: if we deviate too far from original TAXII Spec, and TAXII 2.0 introduces new fields or better names, users may need a glossary to translate TAXII entities into JSON binding entities. We need to find a middle ground here.

Thanks,
Sergey Polzunov
Intelworks



On 09 Apr 2015, at 20:28, Jordan, Bret <[hidden email]> wrote:

maybe change message_bindings -> encoding


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 Apr 9, 2015, at 12:06 PM, Jordan, Bret <[hidden email]> wrote:

Here is my list of proposed field name changes for the JSON Message Binding for TAXII, my wish list… :)

Status Message Type
message_id -> id
status_type -> type
status_details -> details

Discovery Request Type
message_id -> id

Discovery Response Type
message_id -> id
service_instances -> services
service_type -> type
service_version -> version
protocol_binding -> protocol
message_binding -> ??

Collection Information Request Type
message_id -> id

Collection Information Response Type
message_id -> id
collection_name -> name
collection_type -> type
collection_volume -> volume
protocol_binding -> protocol
message_binding -> ??
push_methods -> push_services (so it fits with the others)
receiving_inbox_services -> inbox_services

Managed Collection Subscription Request Type
message_id -> id
collection_name -> name
push_parameters -> push_services
protocol_binding -> protocol
message_binding -> ??

Managed Collection Subscription Response Type
message_id -> id
collection_name -> name
push_parameters -> push_services
poll_instances -> poll_services
protocol_binding -> protocol
message_binding -> ??

Poll Request Type
message_id -> id
collection_name -> name
delivery_parameters -> inbox_services
protocol_binding -> protocol
message_binding -> ??

Poll Response Type
message_id -> id
collection_name -> name

Inbox Message Type
message_id -> id
collection_name -> name

Fulfillment Request Type
message_id -> id
collection_name -> name


And my super super big wish item, that I do not think I will ever get, is we could change Poll to Pull or better yet Get.


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.96.pdf (306K) Download Attachment
signature.asc (858 bytes) Download Attachment