OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]