This issue has been discussed at length over and over. The consensus of the TC is with the text as it is written. From a level of specificity the versioning rules are general and apply to all of STIX object. However, there is a caveat and _additional_ clarification that was given to Custom Properties. That text was well understood, the ramification of it well understood, and what it meant was well understood and debated. This is how standards are written. Broad rules that cover everything and when needed specific sometimes other rules are given for very specific purposes. That was the case here.
It is also important to note that there was a very small and very vocal minority of people that disagreed with that decision that was made by the TC ever so long ago. But the majority made a decision and it has been in the document for a long time, early early on in STIX 2.0.
There are all kinds of issues in STIX that various people, even myself, do not like. If we could go back in time, I am sure we would change some of them. But that is the nature of consensus and community built things.
Bret
On Apr 30, 2021, at 1:00 PM, Jason Keirstead <> wrote:
I need to correct myself before someone jumps all over me...Please add words inside *** to my reply...
The spec is very clear on this... if you *** are not the original producer and you *** change the data in the object in any way when you retransmit, then you must generate a new ID for it. This includes dropping fields, adding fields, or any other change whatsoever.
-Jason KeirsteadDistinguished Engineer, CTO - IBM Security Threat Managementwww.ibm.com/securityCo-Chair - Open Cybersecurity Alliance, Project Governing Board
www.opencybersecurityalliance.org
----- Original message -----From: "Jason Keirstead" <>Sent by: <>To: : : [EXTERNAL] Re: [cti] Preservation of STIXDate: Fri, Apr 30, 2021 3:49 PM
The spec is very clear on this... if you change the data in the object in any way when you retransmit, then you must generate a new ID for it. This includes dropping fields, adding fields, or any other change whatsoever.
TIPs and other systems that consume an SDO and then retransmit it later, but with different fields, MUST do so with new object IDs (which start over at version 1) - and ideally, a new created_by_ref (in the previous 2.0, interop tests, created_by_ref was required as part of interop)If a system is simply dropping fields and re-transmitting with the same ID, then they are not compliant with the spec.
--"STIX Objects have a single object creator, the entity that generates the id for the object and creates the first version. The object creator MAY (but not necessarily will) be identified in the created_by_ref property of the object. Only the object creator is permitted to create new versions of a STIX Object. Producers other than the object creator MUST NOT create new versions of that object. If a producer other than the object creator wishes to create a new version, they MUST instead create a new object with a new id. They SHOULD additionally create a derived-from Relationship object to relate their new object to the original object that it was derived from."
-Jason KeirsteadDistinguished Engineer, CTO - IBM Security Threat Managementwww.ibm.com/securityCo-Chair - Open Cybersecurity Alliance, Project Governing Board
www.opencybersecurityalliance.org
----- Original message -----From: "Taylor, Marlon" <>Sent by: <>To: "" <>Cc:Subject: [EXTERNAL] [cti] Preservation of STIXDate: Mon, Apr 19, 2021 1:40 PM
Hi TC,
What is the TC stance on the preservation of STIX content?
Through engagements with various members of the STIX community it has become apparent that STIX content is handled differently within the community. The difference in STIX handling (e.g. dropped fields) results in confusion and lack of trust between systems. This concern has echoed throughout the STIX community, the Interop subcommittee, and now the TC for the purpose of resolution! This is great timing as we can address this for all while the specification is in public review prior on the way to becoming an OASIS standard!
The table below highlights areas of consideration. The âRow #â column provides an unique identifier of each use case. Iâm we hoping we as a TC can provide a decision on this matter and show alignment via the rows below.
Row #
Ingest - Keep Original
No â the original STIX is a not accessible Yes â the original STIX is accessible
Process - Translate to internal Data Model
None â no STIX properties are mapped to the data model Some â some STIX properties are mapped to the data model All â every STIX property in mapped to the data model
Export â Original
No â the original STIX is not exportable
Yes â the original STIX is exportable
Export â Processed
No â the internal data model is not exportable is STIX
Yes â the internal data model is exportable is STIX
1
No
None
No
No
2
No
None
No
Yes
3
No
None
Yes
No
4
No
None
Yes
Yes
5
No
Some
No
No
6
No
Some
No
Yes
7
No
Some
Yes
No
8
No
Some
Yes
Yes
9
No
All
No
No
10
No
All
No
Yes
11
No
All
Yes
No
12
No
All
Yes
Yes
13
Yes
None
No
No
14
Yes
None
No
Yes
15
Yes
None
Yes
No
16
Yes
None
Yes
Yes
17
Yes
Some
No
No
18
Yes
Some
No
Yes
19
Yes
Some
Yes
No
20
Yes
Some
Yes
Yes
21
Yes
All
No
No
22
Yes
All
No
Yes
23
Yes
All
Yes
No
24
Yes
All
Yes
Yes
Addressing the preservation of STIX as a TC will drive a better understanding for all and interoperability.
Marlon Taylor
<>
