Re: [cti-comment] Additional minor issues with extension examples, etc.

Subject: Re: [cti-comment] Additional minor issues with extension examples, etc.

LeÂjeu. 1 avr. 2021 ÃÂ06:43, Chris Lenk <clenk@mitre.org> a ÃcritÂ:

Building off of the typos in the extension examples pointed out by Mark Finlayson in a previous email and by Emmanuelle Vargas-Gonzalez at https://github.com/oasis-tcs/cti-stix2/issues/238, here are more that I've found:

Â

Section 7.3.2:

Example - Create a new object type:

Both objects' id properties should use UUIDv4 since that is what the spec recommends - they currently use v1 and a variant reserved for backwards compatibility rather than RFC 4122.
In the extensions property of the "my-favorite-sdo" object, make sure there are no spaces around the extension definition identifier (there were in the word doc attached to the previous email).
The "my-favorite-sdo" object uses "new_sdo" as its extension_type, but it should be "new-sdo".

Example - Adding properties to an existing STIX object instance:

Add the required "pattern_type" property.

Adding properties at the top-level to an existing STIX object instance:

Add "Example - " to this header to be consistent with the other examples here.
In the extensions property of the indicator object, make sure there are no spaces around the extension definition identifier (there were in the word doc attached to the previous email).
Remove the comma at the end of the following line:

"extension_type": "toplevel-property-extension",

Example - Adding two new STIX objects and properties to an existing STIX object instance:

The indicator, my-favorite-sdo and extension definition object's id properties should use UUIDv4 since that is what the spec recommends - they currently use v1 and a variant reserved for backwards compatibility rather than RFC 4122.
The extension definition object lacks created and modified properties.
The extension definition object has a "created_by" property - this should be renamed to "created_by_ref" and given a value containing an actual UUID, preferably UUIDv4.

Remove the comma at the end of the following lines:

"extension_type": "new-sdo",
"extension_type": "new-sco",

Appendix C:

C.1.2:

"id": "relationship--7f5b1a34-c64b-4ad4-8a0f-1ebeffaa2d4" needs one more character at the end to make it a valid UUID.

C.2.1:

In the extension definition object, swap the "extension_types" line and "object_marking_refs" line so that the last line in the object doesn't have a comma and the properties match the order in the "Optional Common Properties" tables elsewhere in the spec.
In the "my-favorite-sdo" object, remove the comma at the end of the "extension_type" line.
The "my-favorite-sdo" object's id property should use UUIDv4 since that is what the spec recommends - it currently uses v1 and a variant reserved for backwards compatibility rather than RFC 4122.

C.2.2:

The Indicator object needs a "pattern_type" property.
The artifact object needs a comma after the "decryption_key" line.

C.2.3:

The sighting object needs a comma after the "sighting_of_ref" line.

C.2.4:

The marking definition has the same id as the spec-defined TLP Green marking definition, so it needs a different UUID.

C.2.5:

In the language-content object, add a comma on the line above "extensions".
In the language-content object, the extension-definition--... entry needs a closing "}".

Â

Other minor things found elsewhere in the document:

Â

Table of Contents:

Section 7.2 should not be bolded.

Section 4.6.1 Incident Properties table:

Says "Course of Action Specific Properties".

Section 4.7.1 Indicator Properties table:

The "Indicator Specific Properties" section does not include pattern_type or pattern_version.

Section 5.2.1 Sighting Properties table:

The description of "sighting_of_ref" says it "MUST reference only an SDO or a Custom Object." Does this need to be updated to account for extensions? For example, we might remove the text "or a Custom Object" given the assumption that the term "SDO" includes the SDOs defined in the spec, custom SDOs defined using the now deprecated custom object type mechanism, and custom SDOs defined using a "new-sdo" extension.

Â

Thank you,

Chris Lenk

cti-comment message