[TAXII] JSON schemas for JSON Binding Spec v0.5 and Spec issues

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

[TAXII] JSON schemas for JSON Binding Spec v0.5 and Spec issues

Sergey Polzunov
Good morning,

        I just finished with JSON schema documents for Bret’s JSON Message Binding Spec v.0.5. You can find the schemas and JSON blob samples here - https://github.com/traut/taxii-json-schemas-draft

    Note that conditional requirements (if action == “PAUSE”, subscription_id is required) are not covered just yet.

    Please check README to see how to run validations. If you have any questions/concerns, please mail me or raise an issue on github.


    While creating schemas, I noticed some issues with the Spec itself that I think need to be fixed.
Semantic issues:
        - supported_queries - list or array? If format ID needs to be unique, why not define supported_queries as a dictionary where the key is “format_id” and the value is “query_format”? (TAXII Discovery Response, Table 3.3-1)
        - should we combine query and query_format id into one object? Example: «“query”: {“format_id”:””, “value”: “query value”}». This way we will have one reusable semantic entity that can be referenced in Collection Subscription Request, Collection Subscription Response, Poll Request. That would also simplify parsing.
        - content block has a signature field that can contain multiple strings (Table 3.9-1). Where can I find a description for this field? I haven’t seen anything related in TAXII 1.1 spec

Syntax issues:
        - Value for ACCEPTABLE_DESTINATION field in Status Details is defined as a string, while TAXII 1.1 Specification defines Acceptable Destination field as a list of strings. (Table 3.1-3);
        -  SUPPORTED_BINDING, SUPPORTED_CONTENT, SUPPORTED_PROTOCOL, SUPPORTED_QUERY are all singular names but the values are arrays (plurals). This is confusing, these should be plurals, for example SUPPORTED_BINDINGS. (Table 3.1-3);
        - content_block contains an array, so it should be a plural “content_blocks” (Table 3.9-1)
        - message field should be in Service Instance, not on Discovery Response level (Table 3.3-1);
        - collection_volume, result_part_number, and record_count are string but semantically defined as a non-negative integers. These should be defined as JSON numbers;
        - missing fields from the spec:
                - Inbox Service, Accepted Content not in Discovery Response,
                - Supported Content not in Collection Information Response
                - Content Binding not in Subscription Parameters (Subscription Request and Subscription Response)
                - Content Binding not in Poll Parameters (Poll Request)
                - Content Binding not in Content Block
        - status in Subscription Instance (page 17) must be “UNSUBSCRIBED” and not “UNSUBSCRIBE”;

Errors in examples:
        - “receiving_inbox_services” and “subscription_services" in example 4.5 on page 24 need to be lists not dicts;
        - “message_binding” should be “message_bindings” in example 4.5 on page 24.
        - “False” is not a valid boolean in json (example 4.8 on page 25 and example 4.9 on page  26), should be “false”;

Thanks,
Sergey Polzunov
Intelworks




Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] JSON schemas for JSON Binding Spec v0.5 and Spec issues

Jordan, Bret
Great work on the JSON schemas and validator.  Really cool.

Comments inline below:


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


   While creating schemas, I noticed some issues with the Spec itself that I think need to be fixed.
Semantic issues:
- supported_queries - list or array? If format ID needs to be unique, why not define supported_queries as a dictionary where the key is “format_id” and the value is “query_format”? (TAXII Discovery Response, Table 3.3-1)


BJ: I am in favor of this, this would probably make things a lot easier down the road too.


- should we combine query and query_format id into one object? Example: «“query”: {“format_id”:””, “value”: “query value”}». This way we will have one reusable semantic entity that can be referenced in Collection Subscription Request, Collection Subscription Response, Poll Request. That would also simplify parsing.

BJ:  So what you are saying is:

"query" : {
"some format id" : "some query value"
}

????  And then use this everywhere that we talk about queries?  


- content block has a signature field that can contain multiple strings (Table 3.9-1). Where can I find a description for this field? I haven’t seen anything related in TAXII 1.1 spec

BJ: I pulled this directly from the XML specification and the TAXII spec.  Apparently you can have an array of signatures on the content block versus the entire TAXII message????  @Mark is that correct?


Syntax issues:
- Value for ACCEPTABLE_DESTINATION field in Status Details is defined as a string, while TAXII 1.1 Specification defines Acceptable Destination field as a list of strings. (Table 3.1-3);

BJ: I will fix this in the next version

-  SUPPORTED_BINDING, SUPPORTED_CONTENT, SUPPORTED_PROTOCOL, SUPPORTED_QUERY are all singular names but the values are arrays (plurals). This is confusing, these should be plurals, for example SUPPORTED_BINDINGS. (Table 3.1-3);
- content_block contains an array, so it should be a plural “content_blocks” (Table 3.9-1)
- message field should be in Service Instance, not on Discovery Response level (Table 3.3-1);
- collection_volume, result_part_number, and record_count are string but semantically defined as a non-negative integers. These should be defined as JSON numbers;

BJ: I will make these changes in next version...

- missing fields from the spec:
- Inbox Service, Accepted Content not in Discovery Response,
- Supported Content not in Collection Information Response
- Content Binding not in Subscription Parameters (Subscription Request and Subscription Response)
- Content Binding not in Poll Parameters (Poll Request)
- Content Binding not in Content Block
- status in Subscription Instance (page 17) must be “UNSUBSCRIBED” and not “UNSUBSCRIBE”;


BJ: There is currently an issue tracker to remove Content Binding from TAXII, so I did not include it here, if we are just going to pull it out in the next version.  If I am wrong, and we should include it now, and pull it out in the next version of TAXII, please let me know.


Errors in examples:
- “receiving_inbox_services” and “subscription_services" in example 4.5 on page 24 need to be lists not dicts;
- “message_binding” should be “message_bindings” in example 4.5 on page 24.
- “False” is not a valid boolean in json (example 4.8 on page 25 and example 4.9 on page  26), should be “false”;


BJ: I will fix these in the next version.


Thanks,
Sergey Polzunov
Intelworks






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

Re: [TAXII] JSON schemas for JSON Binding Spec v0.5 and Spec issues

Sergey Polzunov
See my comments inline:

>
>> - should we combine query and query_format id into one object? Example: «“query”: {“format_id”:””, “value”: “query value”}». This way we will have one reusable semantic entity that can be referenced in Collection Subscription Request, Collection Subscription Response, Poll Request. That would also simplify parsing.
>
> BJ:  So what you are saying is:
>
> "query" : {
> "some format id" : "some query value"
> }
>
> ????  And then use this everywhere that we talk about queries?  
>

Yep. These 2 fields are inseparable anyway.

>
>> - content block has a signature field that can contain multiple strings (Table 3.9-1). Where can I find a description for this field? I haven’t seen anything related in TAXII 1.1 spec
>
> BJ: I pulled this directly from the XML specification and the TAXII spec.  Apparently you can have an array of signatures on the content block versus the entire TAXII message????  @Mark is that correct?
>

Does it makes sense to have the signatures on the content level versus message level? What would be the use case?

> BJ: There is currently an issue tracker to remove Content Binding from TAXII, so I did not include it here, if we are just going to pull it out in the next version.  If I am wrong, and we should include it now, and pull it out in the next version of TAXII, please let me know.

Oh, I missed that somehow.

Thanks for the fixes! I’ll align the schemas with 0.6

Sergey Polzunov
Intelworks
Reply | Threaded
Open this post in threaded view
|

[TAXII] TAXII JSON Binding Spec v0.7

Jordan, Bret
I have now implemented all of the changes that I have received.  The comment period will be open for another week and a half, until April 10th, EOD.  Please submit any feedback / changes / suggestions by that time so I can get them incorporated and release a 1.0 version for a formal addition to the standard. I dated this version with tomorrow’s date, since today is full of hoaxes. 


Changes from v0.6

* Updated language in section 1.3.1 to reflect that we have a JSON schema now

* Fixed references to sources throughout the document 

* Made changes to how queries are marked up defined in section 3.6, 3.7, and 3.8 based on feedback and suggestions from the community.

* Fixed hopefully the last pluralization issue in 3.1-3, ACCEPTABLE_DESTINATION to ACCEPTABLE_DESTINATIONS





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

Re: [TAXII] TAXII JSON Binding Spec v0.7

Terry MacDonald
Hi Bret,


In section 2.2.1 It says:

• They MUST follow the ISO 8601 format of YYYY-MM-DDThh:mm:ss+-hh:mm. Note that 'T' is the delimiter between the date and time portions, and the time zone offset is delimited by *either* a '+' or a '-' to indicate the relative offset from UTC.

But then in the next line:

• They MUST include a time zone component (i.e., either "Z" or a numerical offset), in accordance with the date-time production in RFC 3339 [7].

There won't be a Z if the timestamps MUST follow the ISO 8601 format of YYYY-MM-DDThh:mm:ss+-hh:mm. Should the first restriction of ISO8601 be relaxed/removed o ensure a similar date structure to whats allowed in TAXII XML of the same TAXII version? It might confuse people if their XML version is valid and yet their JSON isn't (due to timestamp label differences). Does section 2.2.1 still match the requirements set out in TAXII Services Specification v1.1 section 4.1.4 if that line is left in? 

Cheers
Terry MacDonald


On 2 April 2015 at 03:10, Jordan, Bret <[hidden email]> wrote:
I have now implemented all of the changes that I have received.  The comment period will be open for another week and a half, until April 10th, EOD.  Please submit any feedback / changes / suggestions by that time so I can get them incorporated and release a 1.0 version for a formal addition to the standard. I dated this version with tomorrow’s date, since today is full of hoaxes. 


Changes from v0.6

* Updated language in section 1.3.1 to reflect that we have a JSON schema now

* Fixed references to sources throughout the document 

* Made changes to how queries are marked up defined in section 3.6, 3.7, and 3.8 based on feedback and suggestions from the community.

* Fixed hopefully the last pluralization issue in 3.1-3, ACCEPTABLE_DESTINATION to ACCEPTABLE_DESTINATIONS





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

Jordan, Bret
Those are very good points…  MITRE has updated the best practice documents on the web site to talk about the time stamps needing to be in ISO8601 format for STIX and we should probably do the same for TAXII.  I also need to change that second sentence some how to make it be correct.  Thanks for the catch.  



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 1, 2015, at 1:58 PM, Terry MacDonald <[hidden email]> wrote:

Hi Bret,


In section 2.2.1 It says:

• They MUST follow the ISO 8601 format of YYYY-MM-DDThh:mm:ss+-hh:mm. Note that 'T' is the delimiter between the date and time portions, and the time zone offset is delimited by *either* a '+' or a '-' to indicate the relative offset from UTC.

But then in the next line:

• They MUST include a time zone component (i.e., either "Z" or a numerical offset), in accordance with the date-time production in RFC 3339 [7].

There won't be a Z if the timestamps MUST follow the ISO 8601 format of YYYY-MM-DDThh:mm:ss+-hh:mm. Should the first restriction of ISO8601 be relaxed/removed o ensure a similar date structure to whats allowed in TAXII XML of the same TAXII version? It might confuse people if their XML version is valid and yet their JSON isn't (due to timestamp label differences). Does section 2.2.1 still match the requirements set out in TAXII Services Specification v1.1 section 4.1.4 if that line is left in? 

Cheers
Terry MacDonald


On 2 April 2015 at 03:10, Jordan, Bret <[hidden email]> wrote:
I have now implemented all of the changes that I have received.  The comment period will be open for another week and a half, until April 10th, EOD.  Please submit any feedback / changes / suggestions by that time so I can get them incorporated and release a 1.0 version for a formal addition to the standard. I dated this version with tomorrow’s date, since today is full of hoaxes. 


Changes from v0.6

* Updated language in section 1.3.1 to reflect that we have a JSON schema now

* Fixed references to sources throughout the document 

* Made changes to how queries are marked up defined in section 3.6, 3.7, and 3.8 based on feedback and suggestions from the community.

* Fixed hopefully the last pluralization issue in 3.1-3, ACCEPTABLE_DESTINATION to ACCEPTABLE_DESTINATIONS





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

pmaroney
Brief interjection: advocate that time stamps (and most importantly tooling) support sub millisecond representation per Time-secfrac "." 1*DIGIT.


From: Jordan, Bret <[hidden email]>
Sent: Wednesday, April 1, 2015 5:28:16 PM
To: [hidden email]
Subject: Re: [TAXII] TAXII JSON Binding Spec v0.7
 
Those are very good points…  MITRE has updated the best practice documents on the web site to talk about the time stamps needing to be in ISO8601 format for STIX and we should probably do the same for TAXII.  I also need to change that second sentence some how to make it be correct.  Thanks for the catch.  



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 1, 2015, at 1:58 PM, Terry MacDonald <[hidden email]> wrote:

Hi Bret,


In section 2.2.1 It says:

• They MUST follow the ISO 8601 format of YYYY-MM-DDThh:mm:ss+-hh:mm. Note that 'T' is the delimiter between the date and time portions, and the time zone offset is delimited by *either* a '+' or a '-' to indicate the relative offset from UTC.

But then in the next line:

• They MUST include a time zone component (i.e., either "Z" or a numerical offset), in accordance with the date-time production in RFC 3339 [7].

There won't be a Z if the timestamps MUST follow the ISO 8601 format of YYYY-MM-DDThh:mm:ss+-hh:mm. Should the first restriction of ISO8601 be relaxed/removed o ensure a similar date structure to whats allowed in TAXII XML of the same TAXII version? It might confuse people if their XML version is valid and yet their JSON isn't (due to timestamp label differences). Does section 2.2.1 still match the requirements set out in TAXII Services Specification v1.1 section 4.1.4 if that line is left in? 

Cheers
Terry MacDonald


On 2 April 2015 at 03:10, Jordan, Bret <[hidden email]> wrote:
I have now implemented all of the changes that I have received.  The comment period will be open for another week and a half, until April 10th, EOD.  Please submit any feedback / changes / suggestions by that time so I can get them incorporated and release a 1.0 version for a formal addition to the standard. I dated this version with tomorrow’s date, since today is full of hoaxes. 


Changes from v0.6

* Updated language in section 1.3.1 to reflect that we have a JSON schema now

* Fixed references to sources throughout the document 

* Made changes to how queries are marked up defined in section 3.6, 3.7, and 3.8 based on feedback and suggestions from the community.

* Fixed hopefully the last pluralization issue in 3.1-3, ACCEPTABLE_DESTINATION to ACCEPTABLE_DESTINATIONS





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

Michael P. Stone
In reply to this post by Jordan, Bret

I think it’s the first sentence that should change. (Make the constraint either an offset timezone or the Z.) Both are valid in ISO8601, only the added constraint is problematic.

 

From: Jordan, Bret [mailto:[hidden email]]
Sent: Wednesday, April 01, 2015 5:28 PM
To: [hidden email]
Subject: Re: [TAXII] TAXII JSON Binding Spec v0.7

 

Those are very good points…  MITRE has updated the best practice documents on the web site to talk about the time stamps needing to be in ISO8601 format for STIX and we should probably do the same for TAXII.  I also need to change that second sentence some how to make it be correct.  Thanks for the catch.  

 

 

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 1, 2015, at 1:58 PM, Terry MacDonald <[hidden email]> wrote:

 

Hi Bret,

 

 

In section 2.2.1 It says:

 

• They MUST follow the ISO 8601 format of YYYY-MM-DDThh:mm:ss+-hh:mm. Note that 'T' is the delimiter between the date and time portions, and the time zone offset is delimited by *either* a '+' or a '-' to indicate the relative offset from UTC.

 

But then in the next line:

 

• They MUST include a time zone component (i.e., either "Z" or a numerical offset), in accordance with the date-time production in RFC 3339 [7].

 

There won't be a Z if the timestamps MUST follow the ISO 8601 format of YYYY-MM-DDThh:mm:ss+-hh:mm. Should the first restriction of ISO8601 be relaxed/removed o ensure a similar date structure to whats allowed in TAXII XML of the same TAXII version? It might confuse people if their XML version is valid and yet their JSON isn't (due to timestamp label differences). Does section 2.2.1 still match the requirements set out in TAXII Services Specification v1.1 section 4.1.4 if that line is left in? 


Cheers
Terry MacDonald

 

 

On 2 April 2015 at 03:10, Jordan, Bret <[hidden email]> wrote:

I have now implemented all of the changes that I have received.  The comment period will be open for another week and a half, until April 10th, EOD.  Please submit any feedback / changes / suggestions by that time so I can get them incorporated and release a 1.0 version for a formal addition to the standard. I dated this version with tomorrow’s date, since today is full of hoaxes. 

 

 

Changes from v0.6

 

* Updated language in section 1.3.1 to reflect that we have a JSON schema now

 

* Fixed references to sources throughout the document 

 

* Made changes to how queries are marked up defined in section 3.6, 3.7, and 3.8 based on feedback and suggestions from the community.

 

* Fixed hopefully the last pluralization issue in 3.1-3, ACCEPTABLE_DESTINATION to ACCEPTABLE_DESTINATIONS

 

 

 

 

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

Jordan, Bret
Great idea, I will make that change.   And thanks to everyone for all of their feedback.  I will issue a v0.8 on Sunday/Monday as a last call for comments.   


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 2, 2015, at 8:31 AM, Michael P. Stone <[hidden email]> wrote:

I think it’s the first sentence that should change. (Make the constraint either an offset timezone or the Z.) Both are valid in ISO8601, only the added constraint is problematic.
From: Jordan, Bret [[hidden email]] 
Sent: Wednesday, April 01, 2015 5:28 PM
To: [hidden email]
Subject: Re: [TAXII] TAXII JSON Binding Spec v0.7
 
Those are very good points…  MITRE has updated the best practice documents on the web site to talk about the time stamps needing to be in ISO8601 format for STIX and we should probably do the same for TAXII.  I also need to change that second sentence some how to make it be correct.  Thanks for the catch.  
 

 

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 1, 2015, at 1:58 PM, Terry MacDonald <[hidden email]> wrote:
 
Hi Bret,
 
 
In section 2.2.1 It says:
 
• They MUST follow the ISO 8601 format of YYYY-MM-DDThh:mm:ss+-hh:mm. Note that 'T' is the delimiter between the date and time portions, and the time zone offset is delimited by *either* a '+' or a '-' to indicate the relative offset from UTC.
 
But then in the next line:
 
• They MUST include a time zone component (i.e., either "Z" or a numerical offset), in accordance with the date-time production in RFC 3339 [7].
 
There won't be a Z if the timestamps MUST follow the ISO 8601 format of YYYY-MM-DDThh:mm:ss+-hh:mm. Should the first restriction of ISO8601 be relaxed/removed o ensure a similar date structure to whats allowed in TAXII XML of the same TAXII version? It might confuse people if their XML version is valid and yet their JSON isn't (due to timestamp label differences). Does section 2.2.1 still match the requirements set out in TAXII Services Specification v1.1 section 4.1.4 if that line is left in? 

Cheers
Terry MacDonald
 
 
On 2 April 2015 at 03:10, Jordan, Bret <[hidden email]> wrote:
I have now implemented all of the changes that I have received.  The comment period will be open for another week and a half, until April 10th, EOD.  Please submit any feedback / changes / suggestions by that time so I can get them incorporated and release a 1.0 version for a formal addition to the standard. I dated this version with tomorrow’s date, since today is full of hoaxes. 
 
 
Changes from v0.6
 
* Updated language in section 1.3.1 to reflect that we have a JSON schema now
 
* Fixed references to sources throughout the document 
 
* Made changes to how queries are marked up defined in section 3.6, 3.7, and 3.8 based on feedback and suggestions from the community.
 

* Fixed hopefully the last pluralization issue in 3.1-3, ACCEPTABLE_DESTINATION to ACCEPTABLE_DESTINATIONS

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

mdavidson

A couple of notes here:

 

# Fractional Seconds

 

The TAXII Specification states a set of conformance requirements for Timestamp Labels, once of which being that Timestamp Labels can have between 0-6 fractional seconds (but not more than 6). As noted in the spec, this might be expanded in a future revision of TAXII.

 

# Timezone (or +/-HH:MM vs Z)

 

In TAXII, at least for Timestamp Labels, all that really matters is that all timestamps can be deterministically compared. A Timestamp with a time zone offset of ‘Z’ is equivalent to “+00:00”, and therefore can be compared deterministically with all other timestamps that have a time zone offset. Interestingly (and counter-intuitively, at least for me) timestamps that do not have a time zone offset specified have an unspecified time zone offset (instead of a default offset, which was my initial assumption).

 

For a Message Binding that supports TAXII 1.1 I’d recommend permitting both numerical offsets and ‘Z’, since that’s what’s currently allowed by the TAXII 1.1 XML Message Binding.

 

During the writing of this email, I did note that the Time Zone offset requirement is in the XML Message Binding Spec but not in the Services Spec. I feel like having all the Time Zone requirements in the Services Spec would promote uniformity across all potential message binding specs, and therefore should be moved into the Services Spec. I have created an issue for this on GitHub [1].

 

Thank you.

-Mark

 

[1] https://github.com/TAXIIProject/TAXII-Specifications/issues/69

 

From: Jordan, Bret [mailto:[hidden email]]
Sent: Thursday, April 02, 2015 12:51 PM
To: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: Re: [TAXII] TAXII JSON Binding Spec v0.7

 

Great idea, I will make that change.   And thanks to everyone for all of their feedback.  I will issue a v0.8 on Sunday/Monday as a last call for comments.   

 

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 2, 2015, at 8:31 AM, Michael P. Stone <[hidden email]> wrote:

 

I think it’s the first sentence that should change. (Make the constraint either an offset timezone or the Z.) Both are valid in ISO8601, only the added constraint is problematic.

 

From: Jordan, Bret [[hidden email]] 
Sent: Wednesday, April 01, 2015 5:28 PM
To: [hidden email]
Subject: Re: [TAXII] TAXII JSON Binding Spec v0.7

 

Those are very good points…  MITRE has updated the best practice documents on the web site to talk about the time stamps needing to be in ISO8601 format for STIX and we should probably do the same for TAXII.  I also need to change that second sentence some how to make it be correct.  Thanks for the catch.  

 

 

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 1, 2015, at 1:58 PM, Terry MacDonald <[hidden email]> wrote:

 

Hi Bret,

 

 

In section 2.2.1 It says:

 

• They MUST follow the ISO 8601 format of YYYY-MM-DDThh:mm:ss+-hh:mm. Note that 'T' is the delimiter between the date and time portions, and the time zone offset is delimited by *either* a '+' or a '-' to indicate the relative offset from UTC.

 

But then in the next line:

 

• They MUST include a time zone component (i.e., either "Z" or a numerical offset), in accordance with the date-time production in RFC 3339 [7].

 

There won't be a Z if the timestamps MUST follow the ISO 8601 format of YYYY-MM-DDThh:mm:ss+-hh:mm. Should the first restriction of ISO8601 be relaxed/removed o ensure a similar date structure to whats allowed in TAXII XML of the same TAXII version? It might confuse people if their XML version is valid and yet their JSON isn't (due to timestamp label differences). Does section 2.2.1 still match the requirements set out in TAXII Services Specification v1.1 section 4.1.4 if that line is left in? 


Cheers
Terry MacDonald

 

 

On 2 April 2015 at 03:10, Jordan, Bret <[hidden email]> wrote:

I have now implemented all of the changes that I have received.  The comment period will be open for another week and a half, until April 10th, EOD.  Please submit any feedback / changes / suggestions by that time so I can get them incorporated and release a 1.0 version for a formal addition to the standard. I dated this version with tomorrow’s date, since today is full of hoaxes. 

 

 

Changes from v0.6

 

* Updated language in section 1.3.1 to reflect that we have a JSON schema now

 

* Fixed references to sources throughout the document 

 

* Made changes to how queries are marked up defined in section 3.6, 3.7, and 3.8 based on feedback and suggestions from the community.

 

* Fixed hopefully the last pluralization issue in 3.1-3, ACCEPTABLE_DESTINATION to ACCEPTABLE_DESTINATIONS

 

 

 

 

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

Terry MacDonald
I have a question.... should we force all times in STIX v2.0 to be UTC/GMT? Then there wouldn't need to be any need for time conversion and potentially less need for a remote implementation to understand when my local timezone changes from Standard Time  to Daylight Savings Time. We'd all be operating on the same timezone (UTC/GMT)

Cheers
Terry MacDonald


On 6 April 2015 at 21:54, Davidson II, Mark S <[hidden email]> wrote:

A couple of notes here:

 

# Fractional Seconds

 

The TAXII Specification states a set of conformance requirements for Timestamp Labels, once of which being that Timestamp Labels can have between 0-6 fractional seconds (but not more than 6). As noted in the spec, this might be expanded in a future revision of TAXII.

 

# Timezone (or +/-HH:MM vs Z)

 

In TAXII, at least for Timestamp Labels, all that really matters is that all timestamps can be deterministically compared. A Timestamp with a time zone offset of ‘Z’ is equivalent to “+00:00”, and therefore can be compared deterministically with all other timestamps that have a time zone offset. Interestingly (and counter-intuitively, at least for me) timestamps that do not have a time zone offset specified have an unspecified time zone offset (instead of a default offset, which was my initial assumption).

 

For a Message Binding that supports TAXII 1.1 I’d recommend permitting both numerical offsets and ‘Z’, since that’s what’s currently allowed by the TAXII 1.1 XML Message Binding.

 

During the writing of this email, I did note that the Time Zone offset requirement is in the XML Message Binding Spec but not in the Services Spec. I feel like having all the Time Zone requirements in the Services Spec would promote uniformity across all potential message binding specs, and therefore should be moved into the Services Spec. I have created an issue for this on GitHub [1].

 

Thank you.

-Mark

 

[1] https://github.com/TAXIIProject/TAXII-Specifications/issues/69

 

From: Jordan, Bret [mailto:[hidden email]]
Sent: Thursday, April 02, 2015 12:51 PM
To: taxii-discussion-list Trusted Automated Exchange of Indicator In


Subject: Re: [TAXII] TAXII JSON Binding Spec v0.7

 

Great idea, I will make that change.   And thanks to everyone for all of their feedback.  I will issue a v0.8 on Sunday/Monday as a last call for comments.   

 

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 2, 2015, at 8:31 AM, Michael P. Stone <[hidden email]> wrote:

 

I think it’s the first sentence that should change. (Make the constraint either an offset timezone or the Z.) Both are valid in ISO8601, only the added constraint is problematic.

 

From: Jordan, Bret [[hidden email]] 
Sent: Wednesday, April 01, 2015 5:28 PM
To: [hidden email]
Subject: Re: [TAXII] TAXII JSON Binding Spec v0.7

 

Those are very good points…  MITRE has updated the best practice documents on the web site to talk about the time stamps needing to be in ISO8601 format for STIX and we should probably do the same for TAXII.  I also need to change that second sentence some how to make it be correct.  Thanks for the catch.  

 

 

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 1, 2015, at 1:58 PM, Terry MacDonald <[hidden email]> wrote:

 

Hi Bret,

 

 

In section 2.2.1 It says:

 

• They MUST follow the ISO 8601 format of YYYY-MM-DDThh:mm:ss+-hh:mm. Note that 'T' is the delimiter between the date and time portions, and the time zone offset is delimited by *either* a '+' or a '-' to indicate the relative offset from UTC.

 

But then in the next line:

 

• They MUST include a time zone component (i.e., either "Z" or a numerical offset), in accordance with the date-time production in RFC 3339 [7].

 

There won't be a Z if the timestamps MUST follow the ISO 8601 format of YYYY-MM-DDThh:mm:ss+-hh:mm. Should the first restriction of ISO8601 be relaxed/removed o ensure a similar date structure to whats allowed in TAXII XML of the same TAXII version? It might confuse people if their XML version is valid and yet their JSON isn't (due to timestamp label differences). Does section 2.2.1 still match the requirements set out in TAXII Services Specification v1.1 section 4.1.4 if that line is left in? 


Cheers
Terry MacDonald

 

 

On 2 April 2015 at 03:10, Jordan, Bret <[hidden email]> wrote:

I have now implemented all of the changes that I have received.  The comment period will be open for another week and a half, until April 10th, EOD.  Please submit any feedback / changes / suggestions by that time so I can get them incorporated and release a 1.0 version for a formal addition to the standard. I dated this version with tomorrow’s date, since today is full of hoaxes. 

 

 

Changes from v0.6

 

* Updated language in section 1.3.1 to reflect that we have a JSON schema now

 

* Fixed references to sources throughout the document 

 

* Made changes to how queries are marked up defined in section 3.6, 3.7, and 3.8 based on feedback and suggestions from the community.

 

* Fixed hopefully the last pluralization issue in 3.1-3, ACCEPTABLE_DESTINATION to ACCEPTABLE_DESTINATIONS

 

 

 

 

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

Michael P. Stone

Mandating that all times include a TZ offset already achieves that goal. (I don’t need to know your timezone’s rules, it’s on you to specify the correct offset. If you don’t want to bother, you have the option of running in UTC.) I find it hard to believe that there are implementations that can handle the XML, the object model, and the incredibly complicated relationship model, but can’t figure out the library functions for time.

 

From: Terry MacDonald [mailto:[hidden email]]
Sent: Monday, April 06, 2015 9:14 AM
To: [hidden email]
Subject: Re: [TAXII] TAXII JSON Binding Spec v0.7

 

I have a question.... should we force all times in STIX v2.0 to be UTC/GMT? Then there wouldn't need to be any need for time conversion and potentially less need for a remote implementation to understand when my local timezone changes from Standard Time  to Daylight Savings Time. We'd all be operating on the same timezone (UTC/GMT)


Cheers
Terry MacDonald

 

 

On 6 April 2015 at 21:54, Davidson II, Mark S <[hidden email]> wrote:

A couple of notes here:

 

# Fractional Seconds

 

The TAXII Specification states a set of conformance requirements for Timestamp Labels, once of which being that Timestamp Labels can have between 0-6 fractional seconds (but not more than 6). As noted in the spec, this might be expanded in a future revision of TAXII.

 

# Timezone (or +/-HH:MM vs Z)

 

In TAXII, at least for Timestamp Labels, all that really matters is that all timestamps can be deterministically compared. A Timestamp with a time zone offset of ‘Z’ is equivalent to “+00:00”, and therefore can be compared deterministically with all other timestamps that have a time zone offset. Interestingly (and counter-intuitively, at least for me) timestamps that do not have a time zone offset specified have an unspecified time zone offset (instead of a default offset, which was my initial assumption).

 

For a Message Binding that supports TAXII 1.1 I’d recommend permitting both numerical offsets and ‘Z’, since that’s what’s currently allowed by the TAXII 1.1 XML Message Binding.

 

During the writing of this email, I did note that the Time Zone offset requirement is in the XML Message Binding Spec but not in the Services Spec. I feel like having all the Time Zone requirements in the Services Spec would promote uniformity across all potential message binding specs, and therefore should be moved into the Services Spec. I have created an issue for this on GitHub [1].

 

Thank you.

-Mark

 

[1] https://github.com/TAXIIProject/TAXII-Specifications/issues/69

 

From: Jordan, Bret [mailto:[hidden email]]
Sent: Thursday, April 02, 2015 12:51 PM
To: taxii-discussion-list Trusted Automated Exchange of Indicator In


Subject: Re: [TAXII] TAXII JSON Binding Spec v0.7

 

Great idea, I will make that change.   And thanks to everyone for all of their feedback.  I will issue a v0.8 on Sunday/Monday as a last call for comments.   

 

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 2, 2015, at 8:31 AM, Michael P. Stone <[hidden email]> wrote:

 

I think it’s the first sentence that should change. (Make the constraint either an offset timezone or the Z.) Both are valid in ISO8601, only the added constraint is problematic.

 

From: Jordan, Bret [[hidden email]
Sent: Wednesday, April 01, 2015 5:28 PM
To: [hidden email]
Subject: Re: [TAXII] TAXII JSON Binding Spec v0.7

 

Those are very good points…  MITRE has updated the best practice documents on the web site to talk about the time stamps needing to be in ISO8601 format for STIX and we should probably do the same for TAXII.  I also need to change that second sentence some how to make it be correct.  Thanks for the catch.  

 

 

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 1, 2015, at 1:58 PM, Terry MacDonald <[hidden email]> wrote:

 

Hi Bret,

 

 

In section 2.2.1 It says:

 

• They MUST follow the ISO 8601 format of YYYY-MM-DDThh:mm:ss+-hh:mm. Note that 'T' is the delimiter between the date and time portions, and the time zone offset is delimited by *either* a '+' or a '-' to indicate the relative offset from UTC.

 

But then in the next line:

 

• They MUST include a time zone component (i.e., either "Z" or a numerical offset), in accordance with the date-time production in RFC 3339 [7].

 

There won't be a Z if the timestamps MUST follow the ISO 8601 format of YYYY-MM-DDThh:mm:ss+-hh:mm. Should the first restriction of ISO8601 be relaxed/removed o ensure a similar date structure to whats allowed in TAXII XML of the same TAXII version? It might confuse people if their XML version is valid and yet their JSON isn't (due to timestamp label differences). Does section 2.2.1 still match the requirements set out in TAXII Services Specification v1.1 section 4.1.4 if that line is left in? 


Cheers
Terry MacDonald

 

 

On 2 April 2015 at 03:10, Jordan, Bret <[hidden email]> wrote:

I have now implemented all of the changes that I have received.  The comment period will be open for another week and a half, until April 10th, EOD.  Please submit any feedback / changes / suggestions by that time so I can get them incorporated and release a 1.0 version for a formal addition to the standard. I dated this version with tomorrow’s date, since today is full of hoaxes. 

 

 

Changes from v0.6

 

* Updated language in section 1.3.1 to reflect that we have a JSON schema now

 

* Fixed references to sources throughout the document 

 

* Made changes to how queries are marked up defined in section 3.6, 3.7, and 3.8 based on feedback and suggestions from the community.

 

* Fixed hopefully the last pluralization issue in 3.1-3, ACCEPTABLE_DESTINATION to ACCEPTABLE_DESTINATIONS

 

 

 

 

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

pmaroney
In reply to this post by mdavidson
Mark,

Many thanks for circling back on this.  We do need to have a sidebar on the implementation specific issues with tooling, libraries, and frameworks that don't consistently support fractional seconds (e.g. Ruby supports nanseconds, x supports microseconds, y supports milliseconds, z does not support at all).  If nothing else a community managed wiki like reference table/guide with perhaps shared conventions for workarounds.

Also can't recall (apologies if we addressed this) where we are on representing Timestamps consistently in all places in STIX/CybOx, TAXII standards and community provided tooling. If we have not specifically addressed this yet, we should put it on the issues lists for addressing in v2 discussions.

Patrick Maroney
Office: (856)983-0001
Cell: (609)841-5104
[hidden email]
________________________________
From: Davidson II, Mark S <[hidden email]>
Sent: Monday, April 6, 2015 7:54:46 AM
To: [hidden email]
Subject: Re: [TAXII] TAXII JSON Binding Spec v0.7

A couple of notes here:

# Fractional Seconds

The TAXII Specification states a set of conformance requirements for Timestamp Labels, once of which being that Timestamp Labels can have between 0-6 fractional seconds (but not more than 6). As noted in the spec, this might be expanded in a future revision of TAXII.

# Timezone (or +/-HH:MM vs Z)

In TAXII, at least for Timestamp Labels, all that really matters is that all timestamps can be deterministically compared. A Timestamp with a time zone offset of ‘Z’ is equivalent to “+00:00”, and therefore can be compared deterministically with all other timestamps that have a time zone offset. Interestingly (and counter-intuitively, at least for me) timestamps that do not have a time zone offset specified have an unspecified time zone offset (instead of a default offset, which was my initial assumption).

For a Message Binding that supports TAXII 1.1 I’d recommend permitting both numerical offsets and ‘Z’, since that’s what’s currently allowed by the TAXII 1.1 XML Message Binding.

During the writing of this email, I did note that the Time Zone offset requirement is in the XML Message Binding Spec but not in the Services Spec. I feel like having all the Time Zone requirements in the Services Spec would promote uniformity across all potential message binding specs, and therefore should be moved into the Services Spec. I have created an issue for this on GitHub [1].

Thank you.
-Mark

[1] https://github.com/TAXIIProject/TAXII-Specifications/issues/69

From: Jordan, Bret [mailto:[hidden email]]
Sent: Thursday, April 02, 2015 12:51 PM
To: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: Re: [TAXII] TAXII JSON Binding Spec v0.7

Great idea, I will make that change.   And thanks to everyone for all of their feedback.  I will issue a v0.8 on Sunday/Monday as a last call for comments.

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 2, 2015, at 8:31 AM, Michael P. Stone <[hidden email]<mailto:[hidden email]>> wrote:

I think it’s the first sentence that should change. (Make the constraint either an offset timezone or the Z.) Both are valid in ISO8601, only the added constraint is problematic.

From: Jordan, Bret [mailto:[hidden email]]
Sent: Wednesday, April 01, 2015 5:28 PM
To: [hidden email]<mailto:[hidden email]>
Subject: Re: [TAXII] TAXII JSON Binding Spec v0.7

Those are very good points…  MITRE has updated the best practice documents on the web site to talk about the time stamps needing to be in ISO8601 format for STIX and we should probably do the same for TAXII.  I also need to change that second sentence some how to make it be correct.  Thanks for the catch.


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 1, 2015, at 1:58 PM, Terry MacDonald <[hidden email]<mailto:[hidden email]>> wrote:

Hi Bret,


In section 2.2.1 It says:

• They MUST follow the ISO 8601 format of YYYY-MM-DDThh:mm:ss+-hh:mm. Note that 'T' is the delimiter between the date and time portions, and the time zone offset is delimited by *either* a '+' or a '-' to indicate the relative offset from UTC.

But then in the next line:

• They MUST include a time zone component (i.e., either "Z" or a numerical offset), in accordance with the date-time production in RFC 3339 [7].

There won't be a Z if the timestamps MUST follow the ISO 8601 format of YYYY-MM-DDThh:mm:ss+-hh:mm. Should the first restriction of ISO8601 be relaxed/removed o ensure a similar date structure to whats allowed in TAXII XML of the same TAXII version? It might confuse people if their XML version is valid and yet their JSON isn't (due to timestamp label differences). Does section 2.2.1 still match the requirements set out in TAXII Services Specification v1.1 section 4.1.4 if that line is left in?

Cheers
Terry MacDonald


On 2 April 2015 at 03:10, Jordan, Bret <[hidden email]<mailto:[hidden email]>> wrote:
I have now implemented all of the changes that I have received.  The comment period will be open for another week and a half, until April 10th, EOD.  Please submit any feedback / changes / suggestions by that time so I can get them incorporated and release a 1.0 version for a formal addition to the standard. I dated this version with tomorrow’s date, since today is full of hoaxes.


Changes from v0.6

* Updated language in section 1.3.1 to reflect that we have a JSON schema now

* Fixed references to sources throughout the document

* Made changes to how queries are marked up defined in section 3.6, 3.7, and 3.8 based on feedback and suggestions from the community.

* Fixed hopefully the last pluralization issue in 3.1-3, ACCEPTABLE_DESTINATION to ACCEPTABLE_DESTINATIONS




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

mdavidson
In reply to this post by Michael P. Stone

Folding in Pat’s response to un-split the thread.

 

-Mark

 

 

 

Mark,

 

Many thanks for circling back on this.  We do need to have a sidebar on the implementation specific issues with tooling, libraries, and frameworks that don't consistently support fractional seconds (e.g. Ruby supports nanseconds, x supports microseconds, y supports milliseconds, z does not support at all).  If nothing else a community managed wiki like reference table/guide with perhaps shared conventions for workarounds.

 

Also can't recall (apologies if we addressed this) where we are on representing Timestamps consistently in all places in STIX/CybOx, TAXII standards and community provided tooling. If we have not specifically addressed this yet, we should put it on the issues lists for addressing in v2 discussions.

 

Patrick Maroney

Office: (856)983-0001

Cell: (609)841-5104

[hidden email]

 

 

From: Michael P. Stone [mailto:[hidden email]]
Sent: Monday, April 06, 2015 9:55 AM
To: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: Re: [TAXII] TAXII JSON Binding Spec v0.7

 

Mandating that all times include a TZ offset already achieves that goal. (I don’t need to know your timezone’s rules, it’s on you to specify the correct offset. If you don’t want to bother, you have the option of running in UTC.) I find it hard to believe that there are implementations that can handle the XML, the object model, and the incredibly complicated relationship model, but can’t figure out the library functions for time.

 

From: Terry MacDonald [[hidden email]]
Sent: Monday, April 06, 2015 9:14 AM
To: [hidden email]
Subject: Re: [TAXII] TAXII JSON Binding Spec v0.7

 

I have a question.... should we force all times in STIX v2.0 to be UTC/GMT? Then there wouldn't need to be any need for time conversion and potentially less need for a remote implementation to understand when my local timezone changes from Standard Time  to Daylight Savings Time. We'd all be operating on the same timezone (UTC/GMT)


Cheers
Terry MacDonald

 

 

On 6 April 2015 at 21:54, Davidson II, Mark S <[hidden email]> wrote:

A couple of notes here:

 

# Fractional Seconds

 

The TAXII Specification states a set of conformance requirements for Timestamp Labels, once of which being that Timestamp Labels can have between 0-6 fractional seconds (but not more than 6). As noted in the spec, this might be expanded in a future revision of TAXII.

 

# Timezone (or +/-HH:MM vs Z)

 

In TAXII, at least for Timestamp Labels, all that really matters is that all timestamps can be deterministically compared. A Timestamp with a time zone offset of ‘Z’ is equivalent to “+00:00”, and therefore can be compared deterministically with all other timestamps that have a time zone offset. Interestingly (and counter-intuitively, at least for me) timestamps that do not have a time zone offset specified have an unspecified time zone offset (instead of a default offset, which was my initial assumption).

 

For a Message Binding that supports TAXII 1.1 I’d recommend permitting both numerical offsets and ‘Z’, since that’s what’s currently allowed by the TAXII 1.1 XML Message Binding.

 

During the writing of this email, I did note that the Time Zone offset requirement is in the XML Message Binding Spec but not in the Services Spec. I feel like having all the Time Zone requirements in the Services Spec would promote uniformity across all potential message binding specs, and therefore should be moved into the Services Spec. I have created an issue for this on GitHub [1].

 

Thank you.

-Mark

 

[1] https://github.com/TAXIIProject/TAXII-Specifications/issues/69

 

From: Jordan, Bret [mailto:[hidden email]]
Sent: Thursday, April 02, 2015 12:51 PM
To: taxii-discussion-list Trusted Automated Exchange of Indicator In


Subject: Re: [TAXII] TAXII JSON Binding Spec v0.7

 

Great idea, I will make that change.   And thanks to everyone for all of their feedback.  I will issue a v0.8 on Sunday/Monday as a last call for comments.   

 

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 2, 2015, at 8:31 AM, Michael P. Stone <[hidden email]> wrote:

 

I think it’s the first sentence that should change. (Make the constraint either an offset timezone or the Z.) Both are valid in ISO8601, only the added constraint is problematic.

 

From: Jordan, Bret [[hidden email]
Sent: Wednesday, April 01, 2015 5:28 PM
To: [hidden email]
Subject: Re: [TAXII] TAXII JSON Binding Spec v0.7

 

Those are very good points…  MITRE has updated the best practice documents on the web site to talk about the time stamps needing to be in ISO8601 format for STIX and we should probably do the same for TAXII.  I also need to change that second sentence some how to make it be correct.  Thanks for the catch.  

 

 

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 1, 2015, at 1:58 PM, Terry MacDonald <[hidden email]> wrote:

 

Hi Bret,

 

 

In section 2.2.1 It says:

 

• They MUST follow the ISO 8601 format of YYYY-MM-DDThh:mm:ss+-hh:mm. Note that 'T' is the delimiter between the date and time portions, and the time zone offset is delimited by *either* a '+' or a '-' to indicate the relative offset from UTC.

 

But then in the next line:

 

• They MUST include a time zone component (i.e., either "Z" or a numerical offset), in accordance with the date-time production in RFC 3339 [7].

 

There won't be a Z if the timestamps MUST follow the ISO 8601 format of YYYY-MM-DDThh:mm:ss+-hh:mm. Should the first restriction of ISO8601 be relaxed/removed o ensure a similar date structure to whats allowed in TAXII XML of the same TAXII version? It might confuse people if their XML version is valid and yet their JSON isn't (due to timestamp label differences). Does section 2.2.1 still match the requirements set out in TAXII Services Specification v1.1 section 4.1.4 if that line is left in? 


Cheers
Terry MacDonald

 

 

On 2 April 2015 at 03:10, Jordan, Bret <[hidden email]> wrote:

I have now implemented all of the changes that I have received.  The comment period will be open for another week and a half, until April 10th, EOD.  Please submit any feedback / changes / suggestions by that time so I can get them incorporated and release a 1.0 version for a formal addition to the standard. I dated this version with tomorrow’s date, since today is full of hoaxes. 

 

 

Changes from v0.6

 

* Updated language in section 1.3.1 to reflect that we have a JSON schema now

 

* Fixed references to sources throughout the document 

 

* Made changes to how queries are marked up defined in section 3.6, 3.7, and 3.8 based on feedback and suggestions from the community.

 

* Fixed hopefully the last pluralization issue in 3.1-3, ACCEPTABLE_DESTINATION to ACCEPTABLE_DESTINATIONS

 

 

 

 

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