I am not against limiting this form customization for the same reasons that I expressed against the deletion or deprecation of Section 11. Particularly for a revision to STIX 2.1 CS 01 (6 months old at this point) and not a new version.
Therefore I might not be the best person to suggest a change in the google doc if the TC decides to limit. Others might find this as an addressable concern and hence, why I decided to write in the list for awareness. I did not remember this being mentioned
when the proposal was presented to TC members.
I do agree that it would be uncommon, but as with Section 11 removing this ability (the âinformal wayâ of customizing your content) would hurt custom content already out there or those building their products around CS 01 â where these
levels of customization are allowed.
From: aa tt <firstname.lastname@example.org>
Sent: Wednesday, October 7, 2020 3:36 PM
To: Emmanuelle Vargas-Gonzalez <email@example.com>
Cc: Taylor, Marlon <Marlon.Taylor@cisa.dhs.gov>; firstname.lastname@example.org; email@example.com
Subject: Re: [cti] [EXT] [cti] Extension proposal draft in STIX2.1
Please propose any language or changes to the google doc version. You are correct someone could do that however unlikely it is.
The additional observation is that allowing the extensions property in all objects would also allow extensions of the -ext form for any object (SCO, SRO, SDO, Meta). This is another method that producers have at their disposal to customize
their content and it would be conflicting to think about potentially deleting/deprecating Section 11 when this form of extension would still remain valid.
As far as I know, there is/was no intention to stop that form of extension.
Given that the extensions property is a map (<key/value>) SCO extension objects and the new SEP objects can co-exist in the same structure/map. Their key formats are different are therefore unique so that consumers can differentiate between
them if both are used in the same object.
If the TC feels that some spec language should clarify somehow then please suggest what that language would be and where it should be placed.
Another question for discussion. How would the current Extension Proposal address the other areas of the spec that originally had extensions points â SCOs specifically?
It seems that there would the two competing ways to define an extension: the one in the proposal via the extension object, and the one already in the spec (File NTFS Extension, PDF, and so on for other SCOs)
The spec is open in this regard and it be valid for users to define their extension via this method (e.g., ntfs-ext, exfat-ext, etc.)
Hi Marlon - I believe you are specifically referring to using the names of properties.
a) Disallowed for top-level extensions. Otherwise chaos ensues.
b) Allowed for sub-component extensions with strong guidance to *not* use the same names as properties on any object that may contain the extension because this would be confusing.
On this last point I could be convinced to say that no extension should ever use the same name as any STIX property ever.
How would the extension proposal address overwriting existing STIX properties?
CAUTION: This email originated from outside of
DHS. DO NOT click links or open attachments unless you recognize and/or trust the sender. Contact your component SOC with questions or concerns.
Thank you for your message.
> 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:
I got your point and I agree with you.
In an extreme case, it is up to TIP implementations to raise errors even if
they receive perfectly STIX 2.1-compliant STIX files without custom/extension contents.
What I believe important is the "capability to ignore unknown custom/extension contents"
of TIP implementations, or it would be difficult to gradually introduce
new custom/extension contents. As such, I would go for
> 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.
so that TIP implementations likely have the "capability to ignore unknown custom/extension contents."
> b) Sharing community interoperability compliance/test requirements
> (e.g ISAC defines what is the specific expectations of sharing and consuming intel in that community).
it would be difficult for a sharing community to enforce its members
the interoperability compliance/test requirements to introduce certain new
custom/extension contents, with a hard due date.
The community can introduce custom/extension contents gradually
if each TIP has the "capability to ignore unknown custom/extension contents."
(And I believe this would lead to a wider acceptance of SEP.)
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 188.8.131.52
- 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)