OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Final Review of Identifier Text


All,


Please review this text as soon as possible. This is one of the last two blocking elements that we need to resolve to release working draft 04.  The text is included below and can be found at the following link: https://docs.google.com/document/d/1ShNq4c3e1CkfANmD9O--mdZ5H0O_GLnjN28a_yrEaco/edit#heading=h.64yvzeku5a5c


Bret


2.9 Identifier

Type Name: identifier


An identifier uniquely identifies a STIX Object and MAY do so in a deterministic way. A deterministic identifier means that the identifier generated by more than one producer for the exact same STIX Object using the same namespace, "ID Contributing Properties", and UUID method will have an equivalent identifier value.


All identifiers, excluding those used in the deprecated cyber observable container, MUST follow the form object-type--UUID, where object-type is the exact value (all type names are lowercase strings, by definition) from the type property of the object being identified or referenced and where the UUID MUST be an RFC 4122-compliant UUID [RFC4122].


The UUID part of the identifier MUST be unique across all objects produced by a given producer regardless of the type identified by the object-type prefix. Meaning, a producer MUST NOT reuse the UUID portion of the identifier for objects of different types.


STIX Domain Objects, STIX Relationship Objects, and STIX Helper Objects SHOULD use UUIDv4 for the UUID portion of the identifier. Producers using something other than UUIDv4 need to be mindful of potential collisions and should use a namespace that guarantees uniqueness, however, they MUST NOT use a namespace of 00abedb4-aa42-466c-9c01-fed23315a9b7.


STIX Cyber Observable Objects SHOULD use UUIDv5 for the UUID portion of the identifier and the UUID portion of the UUIDv5-based identifier SHOULD be generated according to the following rules:

  • The namespace SHOULD be 00abedb4-aa42-466c-9c01-fed23315a9b7

  • The value of the name portion SHOULD be the list of "ID Contributing Properties" defined on each SCO and those properties SHOULD be stringified according to JCS [TODO REF] to ensure a canonical representation of the JSON data.

  • Producers not following these rules MUST NOT use a namespace of 00abedb4-aa42-466c-9c01-fed23315a9b7.



STIX Cyber Observable Objects that are used in the deprecated cyber observable container MAY use any string value for the identifier. For the deprecated Cyber Observable Container It is common for implementers to use simple numerical strings for these identifiers (e.g., "0", "1", "2", etc). See section 2.13 for more information (TODO REF).

  • These identifiers, when used inside the deprecated Cyber Observable Objects Container specify a local reference to a Cyber Observable Object. These references MUST be valid within the local scope of the Cyber Observable Object Container (observable-container) that holds both the source Cyber Observable Object and the Cyber Observable Object that it references.

  • These identifiers SHOULD be a non-negative monotonically increasing integer, incrementing by 1 from a starting value of 0, and represented as a string within the JSON MTI serialization. However, implementers MAY elect to use an alternate key format if necessary.


Using Identifiers:

Consumers of STIX Cyber Threat Intelligence that are processing the objects property of an Observed-Data object can assume that the identifier is an old deprecated Cyber Observable Container identifier. Consumers can also inspect the identifier to see if it contains an object-type, if not, they can assume that it is a deprecated Cyber Observable Container identifier. If it does have an object-type and it matches a SCO, then chances are it is a UUIDv5 deterministic identifier, but this can be verified by inspecting the UUID portion of the identifier. RFC 4122 (TODO REF) defines how one can distinguish between a UUIDv4 and UUIDv5 value.


The JSON MTI serialization uses the JSON string type [RFC8259] when representing identifier.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]