We discussed this option a lot in the past... And IMO, on the surface, it feels like a great compromise. But when we went through the workflow in the past, things begin to break down and thus community consensus was we would only do UUIDv4.
To this point, the co-chairs have talked about documenting some of these design decisions in a FAQ to help people understand why we went the ways we did.
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 Mar 14, 2016, at 10:43, Mates, Jeffrey CIV DC3/DCCI <> wrote:
I certainly understand concerns about deterministic IDs breaking workflows and not working in a number of potential use cases. It might make sense to simply allow IDs to follow the UUID v4 and UUID v5 specs. That way organizations that want to use deterministic IDs can, while those that don't have no need to. Ultimately because of how the UUID spec works out both will have the same length, and an outside observer will only notice a single character change between the two.From a parsing standpoint handling something like xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx instead of xxxxxxxx-xxxx-5xxx-xxxx-xxxxxxxxxxxx is pretty trivial as both will accomplish the same thing.Jeffrey Mates, Civ DC3/DCCI~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Computer ScientistDefense Cyber Crime [email protected] Message-----From: [mailto:] On Behalf Of Jordan, BretSent: Monday, March 14, 2016 12:09 PMTo: Mark DavidsonCc: Mates, Jeffrey CIV DC3/DCCI; Jason Keirstead; Taylor, Marlon; ; : Re: [cti] RE: [Non-DoD Source] RE: [cti] RE: Versioning Background DocsAnd for further clarification and to support Trey's statements. This TC talked about deterministic IDs at great length and it was decided that we would not go down that path. With Mark, I believe we have strong consensus to stick with the current ID patterns we have. If this is not the case, then we will need to take this to a ballot. Things like IDs are fundamental and we need to figure these out before we do anything else. Thus the reason we had this discussion a few months ago. Deterministic IDs may offer interesting use cases but also run the risk of breaking a lot of workflow that we are now building. Thanks,BretBret Jordan CISSPDirector 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 Mar 14, 2016, at 10:03, Mark Davidson <> wrote: Jeff, Can you help me understand your perspective? In STIX 1.x, versioning was handled using the timestamp field (and would seem to align with your post, unless I’m mis-reading it) but I’m not sure I’ve seen any discussion about using timestamp for versioning in 2.0. Are you proposing that we use timestamps for versioning in 2.0, or am I misunderstanding your comment? Thank you. -Mark On 3/14/16, 11:52 AM, "Mates, Jeffrey CIV DC3/DCCI" < on behalf of > wrote: My understanding is that in general versioning should be handled using the CTI Core "created_at" attribute which exists on both objects and relationships. If this changes any object with a deterministic hash would also have its GUID change. As such different versions of an object would respect each other's unique GUIDs thus protecting referential integrity. Even without a deterministic hash this would still be possible by simply generating a new GUID every time a new version of an object or relationship is produced. Jeffrey Mates, Civ DC3/DCCI ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Computer Scientist Defense Cyber Crime Institute 410-694-4335 -----Original Message----- From: [mailto:] On Behalf Of Jason Keirstead Sent: Monday, March 14, 2016 11:27 AM To: Taylor, Marlon Cc: ; Mates, Jeffrey CIV DC3/DCCI; Subject: [Non-DoD Source] RE: [cti] RE: Versioning Background Docs Are you saying that versions will only exist on relationship objects? How will that help me figure out if a given threat actor's description is the most recent. - Jason Keirstead STSM, 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 Inactive hide details for "Taylor, Marlon" ---03/14/2016 12:07:46 PM---Correct. Hashing won't provide that capability. Relation"Taylor, Marlon" ---03/14/2016 12:07:46 PM---Correct. Hashing won't provide that capability. Relationships will provide what you're looking for. From: "Taylor, Marlon" <> To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Mates, Jeffrey CIV DC3/DCCI" <>, "" <>, "" <> Date: 03/14/2016 12:07 PM Subject: RE: [cti] RE: Versioning Background Docs ________________________________ Correct. Hashing won't provide that capability. Relationships will provide what you're looking for. -Marlon ________________________________ From: Jason Keirstead Sent: Monday, March 14, 2016 10:56:04 AM To: Taylor, Marlon Cc: Mates, Jeffrey CIV DC3/DCCI; ; Subject: RE: [cti] RE: Versioning Background Docs Apologize for my confusion but I don't really understand what is being discussed in this thread. Are people talking about IDs or Versions? What does hashing have to do with versioning? I (hope?) people are not advocating to simply hash the contents of the object and use that as a version? That is not workable. A version has to be continually incrementing. I need to be able to look at a version and know if it is the latest version or if it is stale. You can't do that with hashes. - Jason Keirstead STSM, 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 Inactive hide details for "Taylor, Marlon" ---03/14/2016 11:42:28 AM---Hi All, Jeff and I spoke offline and we are in agreement"Taylor, Marlon" ---03/14/2016 11:42:28 AM---Hi All, Jeff and I spoke offline and we are in agreement with the hash based approach. Some takeaway From: "Taylor, Marlon" <> To: "Mates, Jeffrey CIV DC3/DCCI" <>, "" <> Cc: "" <> Date: 03/14/2016 11:42 AM Subject: RE: [cti] RE: Versioning Background Docs Sent by: <> ________________________________ Hi All, Jeff and I spoke offline and we are in agreement with the hash based approach. Some takeaways: - cleared up "shallowness" of shallow objects - conveyed the idea of relationships which contain arrays of ids (he calls them link aggregators) As we finalize objects across the TC we can go into object-specific required fields. Ex: should every Indicator have an observable? Keep up the feedback. -Marlon ________________________________
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
