Re: [cti] RE: [Non-DoD Source] RE: [cti] RE: Versioning Background Docs

[Patrick Maroney <Pmaroney@Specere.org>]

I am NOT revisiting the discussion on Deterministic IDs at this point (while reserving the right to do so at a later time per our agreements on pathways for rapid progress).  However, I do want to clarify the misrepresentations of what was proposed.  

Deterministic Object IDs as proposed are based *solely* on the immutable , non-subjective, and therefore actionable IOCs  (IOC Class/Type + IOC Value).  When constructured with the source namespace (and obfuscated sub-namespace) of the organization making the assertion, they provide provenance, path traceability, and help to prevent/detect "parroting".

Let's move on with 'random' UUIDv4 Object IDs,  and focus our attention on Relationships, Patterning, and Versioning.

Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org

_____________________________
From: Jordan, Bret <bret.jordan@bluecoat.com>
Sent: Monday, March 14, 2016 7:43 PM
Subject: Re: [cti] RE: [Non-DoD Source] RE: [cti] RE: Versioning Background Docs
To: John-Mark Gurney <jmg@newcontext.com>
Cc: <cti@lists.oasis-open.org>, <marlon.taylor@us-cert.gov>, Mates, Jeffrey CIV DC3/DCCI <jeffrey.mates@dc3.mil>, Mark Davidson <mdavidson@soltra.com>, Jason Keirstead <jason.keirstead@ca.ibm.com>, Taylor, Marlon <marlon.taylor@hq.dhs.gov>


UUIDv5 (deterministic hash based) IDs seems good on the surface.  It is when you dive deep in to the guts of the workflow that you find that they make a mess of everything.  

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 17:37, John-Mark Gurney < jmg@newcontext.com> wrote:

Mates, Jeffrey CIV DC3/DCCI wrote this message on Mon, Mar 14, 2016 at 16:43 +0000:

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.

I don't necessarily see an issue w/ this, BUT if they do this, then
author of the object MUST NOT revision their object, and they can't
even revoke the object either, since the hash of the revoked object
will not match the original object.

--
John-Mark