Re: [cti-stix] STIX Open Issues, #36 and #55

All,

FireEye perspective is that we should not treat Issue #36 as a special case and use different hash structure.

The most obvious rationale for that position is avoiding multiple ways to do something.

Digging below that, we do not believe that it would be appropriate to attempt to constrain the hash specification for ExternalReferences and/or Artifacts based on real-world use cases.

For differing STIX production use cases and different contexts of resource curation (the actual owner/maintainers of the referenced resources which will often be outside the context of the STIX producer) it is not appropriate to attempt to constrain assertion/conveyance of hashes to a single algorithm/value.

A VERY simplistic summarization of some of the relevant complexity in this consideration could include:

There are some cases where the referenced resource has no hash specified by its curator due to the complexity of the resource itself which would make a hash impractical or meaningless. For these cases, producers of STIX content will most likely want to convey no hash along with the reference.
There are some cases where the referenced resource has no hash specified by its curator even though such a hash is feasible.
1. For these cases, producers of STIX content may wish to convey no hash along with the reference or may wish to self-calculate a hash and convey it with the reference.

i. For situations where a hash may be self-calculated, there is not really a single hash algorithm accepted as default by the broad range of sub-domains exchanging STIX content of for that matter curating resources that may be referenced. Some content types or operational/policy environments (some policy environments may dictate a specific hash algorithm) may benefit from different hashing algorithms. It would be unduly constraining to attempt to dictate a single mandatory algorithm across this spectrum.

That being said, we would not object to a SHOULD statement for a given hash algorithm such as SHA-256 but would object to a MUST for a single algorithm or for implicit or explicit MUST NOT for other hash algorithms.

There are some cases where the referenced resource has a hash (or hashes) specified by its curator. The range of potentially relevant referenceable resources will span a range of hash algorithms and it would be most appropriate for producers of STIX content to convey all provided hashes along with the reference. Explicitly limiting the hash options to a single algorithm and value would artificially constrain the inherent usefulness of the existing ecosystem of referenceable resources.

The net of all of the above is that we believe it is most appropriate to utilize a hash structure for ExternalReferences and Artifacts that allows conveyance of any hash algorithm/value that is appropriate including the ability to convey multiple algorithm/value instances for a given reference.

Sean Barnum

Principal Architect

FireEye

M: 703.473.8262

E: sean.barnum@fireeye.com

From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Tuesday, February 27, 2018 at 4:45 PM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] STIX Open Issues, #36 and #55

Hi all,

On the February 27 working call (notes here: https://www.oasis-open.org/committees/document.php?document_id=62614&wg_abbrev=cti) we discussed two STIX issues. Please see the notes for the full discussion at the F2F and the github issues for a longer history…I’m just going to summarize the current state and consensus here.

We reached or confirmed consensus on both topics, so in the absence of any new objections or information before next Friday, March 9, we’ll go ahead and make these changes in the STIX 2.1 drafts.

Thanks,

John

Issue #36, the hashes property on external references (https://github.com/oasis-tcs/cti-stix2/issues/36)

Problem: External references (and artifact type) both allow for producers to include hashes so that consumers can validate that the content they link to matches what the producer meant. In STIX 2.0, there was a long list of hashes and no guidance about which one should be used. That meant that consumers didn’t have confidence that when they implemented support for one or more hashes that producers would use those hashes (though of course people do tend to gravitate to a small set of hashes, it isn’t assured). It would be better for interoperability if there was a recommended or required hash.

Consensus: There was a ballot on the working call, with 11 people voting to add a SHOULD to the specification recommending SHA256 in general for hashes, and 4 people voting to remove the old `hashes` property and add a field specifically for `sha256_hash` (on external references and artifact).

Issue #55, the spec_version property on bundle (https://github.com/oasis-tcs/cti-stix2/issues/55)

Problem: The original issue was that bundle did not have a normative statement saying that all content in the bundle had to be the same version. Upon discussion at the F2F, the community realized that it might make sense to not lock content in a bundle to a single version. After discussion, the consensus was to remove `spec_version` from `bundle` and add it to individual objects.

Consensus: After a discussion on the call there were no new arguments and so the consensus from the F2F was maintained, though not unanimously. The result is a proposal to remove `spec_version` from `bundle` and add it to individual objects.

cti-stix message