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: Re: [cti] Identifier is STIX


Sean â Iâm not opposed to UUIDv5. Quite the opposite. I was in favor of UUIDv5 for SDO ids before and still am. I agree the decision to use UUIDv4 was not the best decision.

 

That said, text and words matter when it comes to definitions. Unifying the definitions of how a SDO id gets generated vs a SCO id *sounds* like yet more attempts to ignore the use cases we have identified previously on why a SCO is *not* a SDO and vis-versa.

 

So if we can see a combined spec with all changes for the work we did at the F2F and *then* iterate on them that might go some way to removing concerns that what was agreed to at the F2F and also leading up to it are not just disappearing as part of an editing process.

 

Right now it feels like we are throwing away agreements that took weeks to get.

 

Regards

 

Allan

 

From: Sean Barnum <sean.barnum@FireEye.com>
Date: Friday, February 8, 2019 at 2:16 PM
To: Allan Thomson <athomson@lookingglasscyber.com>, Bret Jordan <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Identifier is STIX

 

The whole point being discussed here is whether there needs to be any semantic difference between the two and how they are constructed.

 

STIX 2.0 specifies identifier MUST be UUIDv4 and NOT UUIDv5. Many of us have always felt that this was a bad arbitrary decision but were overruled. That is how things work.

Many TC members have now come to the opinion that this arbitrary restriction should be removed and identifiers should be able to be UUIDv4 or UUIDv5.

Once we allow UUIDv5, we are allowing the id to be calculated based on some namespace and string content. As long as the IDs are unique it should NOT matter which namespace a producer uses or how they construct their string to be hashed. Unique is unique.

We should not be putting any more arbitrary restrictions (like which namespace must be used or how the hashed string is constructed) in the spec that are not justified by some need for them.

If a producer decides it is most appropriate for them to use UUIDv4 for a given object then they can.

If a producer decides to use their domain as namespace and a set of object properties to construct the string to be hashed then uses UUIDv5 generation they can.

If a producer decides to use their domain as namespace and some other string content to construct the string to be hashed then uses UUIDv5 generation they can.

As long as all of these meet the unique qualification then they work for the STIX ecosystem.

 

All of these are also valid in the current proposed deterministic-id specification. The only difference I see is that the deterministic-id spec asserts that SHOULD use determinism and SHOULD use the default string construction approach while a change to the identifier spec maybe would want to be a MAY.

If that is the case we can just write a single identifier spec with MAYs and then in Part 3 specifiy that the use of identifier for SCOs SHOULD use the defaults.

 

 

Sean Barnum

Principal Architect

FireEye

M: 703.473.8262

E: sean.barnum@fireeye.com

 

From: <cti@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Friday, February 8, 2019 at 4:57 PM
To: Bret Jordan <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Identifier is STIX

 

A single definition implies single semantic definitions and they are not that.

 

The structural formats may be the same but how the value of the id is constructed are different.

 

Therefore, suggesting that there should be a single definition is misleading and potentially more confusing than helpful.

 

All objects have identifiers of some form. That does not mean they all have the same method of constructing those identifiers.

 

Allan

 

From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Friday, February 8, 2019 at 1:52 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Identifier is STIX

 

All,

 

With the recently requested change from EclecticIQ and others, the STIX IDs now can support UUIDv5 and the definition of the ID is now very close to the definition for the IDs we have for the new Cyber Observables.  It is my personal opinion that we should have a single definition.  Before today, the definitions were pretty far apart, but now, they are very close.  I will copy them below. But basically the only real difference is the Cyber Observable ID allows the creator to use some random hashing algorithm in addition to UUIDv5.  The STIX ID says it has to be either a UUIDv4 or UUIDv5.  

 

 

STIX ID

 

An identifier universally and uniquely identifies a SDO, SRO, Bundle, Language Content, or Marking Definition, or SCO. Identifiers 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 is either an RFC 4122-compliant Version 4 or Version 5 UUID. The UUID MUST be generated according to the algorithm(s) defined in RFC 4122, section 4.4 (Version 4 UUID) or section 4.3 (Version 5 UUID) [RFC4122].

 

For UUIDv5:

  • The namespace MAY be the organization's fully qualified DNS name (example.com) or some other organizational identifier that helps ensure uniqueness globally.
  • The name MAY be all properties, a subset of all properties, an organizational content identifier, a STIX 1.x identifier, or something else.
  • When using properties for the name portion of the UUIDv5, those properties SHOULD be stringified according to JCS [todo ref].


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

 

 

 

Cyber Observable ID

 

A deterministic-id uniquely identifies a STIX Cyber Observable in a deterministic way. Meaning, the ID for the exact same STIX Cyber Observable with the same contributing ID properties and same hash method used by two different producers SHOULD have the same ID value. Identifiers MUST follow the form object-type--hash, 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 hash SHOULD be a UUIDv5 compliant hash.

 

The data for the hash function SHOULD use JCS [ref todo] to build a canonical representation of the JSON data. The properties that SHOULD be included in the hash are defined for each STIX Cyber Observable as ID Contributing Properties.


The JSON MTI serialization uses the JSON string type [RFC8259] when representing
deterministic-id.

 

 

Bret

â

This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.



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