cti message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [cti] Re: [EXT] Re: [cti] Identifier is STIX
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: Bret Jordan <Bret_Jordan@symantec.com>
- Date: Tue, 19 Feb 2019 11:26:51 -0400
UUIDv5 also allows "any arbitrary
hash", because it is up to the producer how the ID is derived within
a given namespace.
All we would need to do is have text
a-la "This is the STIX 2.1 namespace for JCS-derrived hashes - ( provide
a UUID here )"
If one wants to use the standard mechanism,
they use that namespace. Otherwise, they use their own namespace - which
can do whatever they want and define.
-
Jason Keirstead
Lead Architect - IBM Security Connect
www.ibm.com/security
"Things may come to those who wait, but only the things left by those
who hustle." - Unknown
From:
Bret Jordan <Bret_Jordan@symantec.com>
To:
Allan Thomson <athomson@lookingglasscyber.com>,
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date:
02/08/2019 06:03 PM
Subject:
[cti] Re: [EXT]
Re: [cti] Identifier is STIX
Sent by:
<cti@lists.oasis-open.org>
Allan,
The ONLY real difference in the definitions,
even though the words are different, is that the SCO ID allows any arbitrary
hash, not just UUIDs. That is the ONLY difference.
Bret
From: cti@lists.oasis-open.org <cti@lists.oasis-open.org>
on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Sent: Friday, February 8, 2019 2:57 PM
To: Bret Jordan; cti@lists.oasis-open.org
Subject: [EXT] 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 identifieruniversally and uniquely identifies a SDO, SRO, Bundle, Language Content,
or Marking Definition, or SCO. Identifiers MUST follow the form
object-type--UUID,
where object-typeis the exact value (all type names are lowercase strings, by definition)
from the typeproperty of the object being identified or referenced and where the UUIDis either an RFC 4122-compliant Version 4 or Version 5 UUID. The UUIDMUST 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-iduniquely 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 SHOULDhave the same ID value. Identifiers MUST follow the form object-type--hash,
where object-typeis the exact value (all type names are lowercase strings, by definition)
from the typeproperty of the object being identified or referenced and where the hashSHOULD be a UUIDv5 compliant hash.
The data for the hash function SHOULDuse 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
â
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]