[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Re: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level SDO
Agreed.
From:
""cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Struse, Richard J." <rjs@mitre.org>
Date: Thursday, June 15, 2017 at 5:17 AM
To: Bret Jordan <Bret_Jordan@symantec.com>, "Piazza, Rich" <rpiazza@mitre.org>, John-Mark Gurney <jmg@newcontext.com>
Cc: "Wunder, John" <jwunder@mitre.org>, Patrick Maroney <pmaroney@wapacklabs.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, "Back, Greg" <gback@mitre.org>, "Nathan.Reller@jhuapl.edu" <Nathan.Reller@jhuapl.edu>
Subject: Re: [cti] Re: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level SDO
+1 to the idea of extending the use of hashes in the relationship object. While I believe that digitally-signed STIX content is something we need to do, I think it is also clear that it will take some work to get it right. So, perhaps a good first step would be to use John-Mark Gurney’s canonicalization ideas to allow someone to compute a hash(es) for an SDO they are linking to and then store those in the relationship (this would be optional)? Then, later on when I de-reference that relationship I have the option to generate the canonical version of the destination object, hash it and compare the hashes.
For those who haven’t been tracking this, in practice it might look like this:
Rich
From:
<cti@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Wednesday, June 14, 2017 at 8:12 PM
To: "Piazza, Rich" <rpiazza@mitre.org>, John-Mark Gurney <jmg@newcontext.com>
Cc: "Wunder, John A." <jwunder@mitre.org>, Patrick Maroney <pmaroney@wapacklabs.com>, "Jason Mr. Keirstead" <Jason.Keirstead@ca.ibm.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, "Back, Greg" <gback@mitre.org>, "Nathan.Reller@jhuapl.edu"
<Nathan.Reller@jhuapl.edu>
Subject: Re: [cti] Re: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level SDO
My guess is that eventually we will need to add a "hash" value to the relationship object to store a digital hash of the object you are linking to. We have already started to do this in a few places, like external_references.
Bret
From: Piazza, Rich <rpiazza@mitre.org>
Sent: Wednesday, June 14, 2017 2:58:10 PM
To: John-Mark Gurney; Bret Jordan
Cc: Wunder, John A.; Patrick Maroney; Jason Mr. Keirstead; cti@lists.oasis-open.org; Back, Greg; Nathan.Reller@jhuapl.edu
Subject: Re: [cti] Re: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level SDO
I don't think we should give up on the idea of reusing Locations so quickly. Assuming we go with Locations as SDOs, it certainly is a problem if you reuse someone's Location and
they change it from underneath you. I was first thinking that there should be immutable SDOs - in other words, the unique USA Location SDO CAN'T be changed. If we had a set of the common ones (defined in some library/repo somewhere) then we could just
use their ids. Duplicates are allowed, but hopefully few people would need to create their own USA Location SDO. I was thinking of an extra property (on all SDOs?) - final. If final is true for an SDO, then a new version couldn’t be created.
Adding immutable objects to the spec might be a good idea in general, but I think a simpler way to handle this is just to "trust" that the library/repo contains objects that will not change. In other words, locations created by a certain (well-known) identity
(SDO-Immutable-Library) could be reused with little concern that they are going to change. And if they DO change - maybe that is a feature - after all, all those Soviet-Union Location SDOs are no longer too useful...
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]