Working Call Agenda for Tomorrow

[Bret Jordan <Bret_Jordan@symantec.com>]

All,

For the working call tomorrow, we plan on talking about the following STIX and TAXII open items. 

Issue #36, hash property for external references: 

https://github.com/oasis-tcs/cti-stix2/issues/36

The hash property used to verify the content in an external reference retrieved over the web re-uses the hashes type from cyber observables. While for cyber observables the use case was to allow for describing a wide variety of hash functions that might be observed in the wild, for this use case (hashing defined and used by STIX-based tools) the ability to use such a large set of hashes will reduce interoperability.

Options:

1. Change the hash value to a string and define which specific hash to use

2. Add normative text that calls out which hash to use, but leave it as a dictionary

3. Make a mandatory to implement hash, but don't require that it be used.

4. Make individual properties for the hash that is used in the specific version.

In recent discussion on Github, the group seemed to be leaning towards #4. We’ll discuss on the working call to hopefully get consensus.

 

Issue #55, bundle does not require all objects to be the same spec version: 

https://github.com/oasis-tcs/cti-stix2/issues/55

The current version of STIX Bundle does not require that all objects in the bundle be the same spec version. The current text should probably be clarified.

Options:

1. Update the text to say that all objects in a bundle MUST be of the same version

2. Update the spec to allow for multiple versions. Require spec_version on all STIX objects or, if absent, the version in 2.0.

3. Do #2. In addition, define TAXII version media types to allow for mixed content.

In recent discussion on Github, opinion seems to be mixed. We’ll discuss on the working call to hopefully get consensus.

Issue #28, Discovery Resource Does not Clearly Articulate API Root Allowable Values

https://github.com/oasis-tcs/cti-taxii2/issues/28

The current TAXII specification is not clear if API Roots are relative or if they are full URLs. This has been discussed on a working call and at the last F2F. 

Options:

1. Clarify text to say that API Roots are full URLs
2. Clarify text to say that API Roots can be either full URLs or absolute paths 
3. Other

The consensus out of the F2F and previous working calls, was that we need to clarify this text. 

Issue #22, Add clarifying text around the types of errors you should get and when

https://github.com/oasis-tcs/cti-taxii2/issues/22

We probably need to add a bit more clarifying text to the spec to say what should happen under the following conditions, so that people implement this the same way:

• If no data is returned for a filter
  
• If the filter parameters are wrong
  
• If some of the filter parameters are right and some are wrong
  
• Other cases?

Thanks

Bret and John