I know we’re going to discuss this next Tuesday in our working session, but if we’re going down the URI route, isn’t RDF a good example of the pluses and minuses
of this approach? JSON-LD seems to call these things IRIs instead and allows them to be relative, but I still remember working with my first RDF triplestore and hating life as I had to append a bunch of nonsense URIs to the front of my object IDs just because
the model said so.
RDF does allow for blank nodes though – “anonymous resources”. I know this flies against the face of mandating IDs, but I still question the overall idea that
we’re going to successfully persist and avoid rewriting UUIDs across multiple organizations / data stores. Total anonymity versus organizational anonymity might require new UUIDs anyway, breaking the provenance.
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Barnum, Sean D.
Sent: Thursday, January 21, 2016 2:10 PM
To: Jordan, Bret
Cc: Jason Keirstead; Paul Patrick; Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format
The point that I and others are making here is that the “URL” should not be a separate thing. That the ID itself can be in the form of a URI. For those who do
not wish to make it resolvable, cool they don’t have to. For those who do, they can.
What do you do with all of the groups that are NOT going to include the URL? It seems like having it be part of the ID, but at the end, makes it super ease to
parse or not parse. A simple split on "::" would give you the three tokens.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
I do not see the value in the inconsistency.
Why not simply make it one way of doing things (one that supports all the use cases described so far including enabling use as URI/URL)?
What about:
[object type]::[UUID]::[ID Domain Authority OR URL] and this last part could be optional. This would solve everyone's concern?
Intel Group Foo shares an Indicator "indicator::UUID" with ISAO Bar. When Bar sends you a relationship object they can tack on their ID Domain to the end, so
that people know they MIGHT be able to go back to ISAO Bar and get more information.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
The problem with burying the URL inside the object is it does not really support many of the use cases being discussed.
The point is that the ID for the content can be used in an unambiguous resolvable way without having to parse into the object which for many use cases (e.g. A
relationship without both end objects) you won’t have that object to parse into.
I agree with a fixed format codified into the spec.
My opinion is that the fixed format should be [ID authority domain name]/[object type]/[UUID] in such a way to support URI/URL use.
I would really prefer the ID be a fixed format codified in the spec, and any URL be moved to an optional "external_reference" property. Or utilize the "external_ID"
property discussed previously.
Or, Brett's #2 suggestion and just have a relationship to a "collection" object.
-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security |
www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown
<graycol.gif>"Jordan, Bret" ---01/21/2016 02:32:18 PM---So the real question is, do we want to use a URI/URL or a [namespace]:[object-type]:[UUID]? What if
From:
"Jordan, Bret" <bret.jordan@bluecoat.com>
To:
Paul Patrick <ppatrick@isightpartners.com>
Cc:
"Barnum, Sean D." <sbarnum@mitre.org>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org>
Date:
01/21/2016 02:32 PM
Subject:
Re: [cti-stix] Object ID format
Sent by:
<cti-stix@lists.oasis-open.org>
So the real question is, do we want to use a URI/URL or a [namespace]:[object-type]:[UUID]? What if we did both? Like maybe this:
All discreet objects in CTI MUST include an ID that defined as an object-type plus a version 4 UUID, example "indicator:104abc69-509e-4bf9-b64c-81255292c433". You MAY also
include an optional URL at the end of the ID if you want to map this object back to an actual resource found on a TAXII server, example "indicator:104abc69-509e-4bf9-b64c-81255292c433:https://taxii.somecompany.com/taxii2/collections/neat-indicators/id/104abc69-509e-4bf9-b64c-81255292c433"
OR even better.. We pull this ID UUID stuff in to TAXII land and make sure that objects can be found by their ID. Then you do not need to include a full URL, but just collection location, example "https://taxii.somecompany.com/taxii2/collections/neat-indicators/"
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
On Jan 21, 2016, at 09:16, Paul Patrick <ppatrick@isightpartners.com>
wrote:
I’m supportive of standardizing Object ID format to be based on the form [producer-namespace]:[object-type]:[UUID], especially if that doesn’t prevent the use of URI.
I think Terry correct captured many of the concerns that I had with the F2F proposed solution and I definitely in agreement with John A. about the value of being able to use URLs.
Paul Patrick
iSIGHT Partners
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]
<graycol.gif>
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.
|