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

Hi all,

and here is some other minor thingsÂ

6.7.4 PDF File Extension

The example is not valid, the name or hash is missing.

6.7.6 Windowsâ PE Binary File Extension

The example is not valid, the name or hash is missing.

6.13.2 Windowsâ Process Extension

 The example is not valid, the id of the process is not a valid UUID

Yohann L.

LeÂjeu. 1 avr. 2021 ÃÂ06:43, Chris Lenk <> 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

-- 

Yohann L.