|The top-level properties for an extension was a compromise to support folks that have previously or currently extended STIX in that manner.|
Although I prefer the sub-component mechanism for extension, I donât think we can achieve unification across all orgs to use that mechanism. And therefore, we need to *accept* that top-level customization/extension exists already and weâre just putting some framework in place to declare such a mechanism, while encouraging new extensions to choose the best path for them going forward.
I understand that this is not ideal but I think we have to accept the compromises to move the STIX2.1 spec forward.
It is critical to understand how this new extension design (excluding the recently added toplevel properties extension) is significantly easier for consumers to keep and store extensions that they do not understand.
IMHO we have a problem with the proposal. Right now we are proposing that we keep Custom Properties, but with some text changes. We are also proposing that we have an official way of declaring top level properties, aka custom properties. So now we have two ways of doing the same thing.
I personally do not like the idea of having top level properties that are custom or part of an extension.
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
Rich - I think the rules on republication (i.e. versioning) are clear.
If you are republishing original intel (using the same UUIDs) then you must maintain the entire object (and structure/components) including any composite parts including extensions. This is very clearly stated in the versioning section of the specification.
The interop specification also explicitly tests this. Interop Specification Part 1 - Section 2.4 has multiple test cases and maps those test cases to persona specifically.
This use case primarily relates to systems that act like TIPs/Threat Intel Gateways where they may ingest and republish without modification.
I think the lack of adoption of Interop/STIXPreferred testing regimen (so far) is partly to blame here.
I suggest any changes or improvements, if needed, should be done to the Interop specifications.
On Oct 12, 2020, at 7:44 AM, Richard J Struse <email@example.com
Just getting around to this â
I concur that having extensions silently dropped by intermediaries is not something we want but my reading of the existing STIX spec (i.e. section 3.5) says that if Iâm republishing objects created by others, I am not allowed to change those objects â and that includes removing extensions. For example, if I receive a STIX object with an extension that I do not understand, the spec does not allow me to strip out the extension and retransmit using the original uuid and creator_ref. I might choose to drop the extension and publish under a new uuid and my creator id but thatâs a different story.
Do we need to make this clearer somehow?
Hi Ryu - thanks for your comments.
In general, I think the compliance/policy language in the specification on how custom/extension content should be processed is not changing per se.
In my opinion, the appropriate place for how custom content should be handled is as follows:
a) Interoperability (STIXPreferred) test cases and specifications.
- That is, based on the Interop test specifications there are already defined rules on how to handle custom properties and objects. Those tests should be updated for extensions not just customization.
b) Sharing community interoperability compliance/test requirements (e.g ISAC defines what is the specific expectations of sharing and consuming intel in that community).
- An ISAC should define how they want all intel producers and consumers to handle custom content shared within their community.
- For example, there may be extensions defined in an ISAC that are required to be produced and consumed and it is required that all participants in that ISAC support the extension and not just accept content without that extension.
It is extremely difficult for me to attend the working call (4-5 am JST),
so please let me express my concern here.
(I will leave the same comment in the Google Doc, too.)
> A STIX 2.1 Producer or STIX 2.1 Consumer MAY support STIX extensions as defined in section <insert ref 7>
What happens when a STIX 2.1 consumer receives a STIX file with STIX extensions
that the consumer does not understand?
My expectation is the consumer does NOT dismiss/drop the whole STIX file (as an error),
but that the consumer DOES accept at least what they understand.
Or I am afraid in communities like ISAC/ISAO, where the community members might be
using different TIP products. It would be difficult for the community to introduce
community-specific extensions if some of the products used in the community
drop the whole STIX with some unknown extensions.
All - I would like to bring attention to some enhancements to the extension proposal (pun intended :-)) that were recently updated (today).
Upon review of the proposal it was thought that it would be useful to allow an extension to include the option for both new object(s) as well as additions to existing objects for SDO, SCO and SRO.
Therefore, when declaring an extension the option to define that it includes those multiple options was desired.
The change was to update the specification of the extension declaration object, from a boolean property to a list property which declares what options were included in the extension.
To support this change we added an enumeration for all types of extensions in section 10.
The working call next Tuesday will cover the proposal as well as any further feedback. Please come prepared or post to the email list with your feedback.
All - We have updated a draft version of STIX2.1 to include the changes for STIX Extensions.
- Section 7 (new object called Extension inserted after marking definition), Section 7.1.1, Section 184.108.40.206
- Section 12.3.3/Section 12.3.4
Also look at the google doc comment history. It has all the changes and you can just click on each one to take you to the specific details.
There will be a separate TC working call to review any further changes but any comments posted in google doc would be greatly accelerate the review.
Allan (on behalf of the SEP proponents)