Re: [cti-stix] Custom properties

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

I am still not sure of this "domain name" syntax. Say IBM and Newcontext and LookingGlass all get in a room and decide in our secret-squirrel-club that we will all support the "uber" property for indicators. Whose domain name do we prefix it with? Is it a fight to the death? IMO this is a very important question because in reality, this is how custom properties will very often be used. A couple of vendors will want to inter-operate on some level that is not yet part of the standard, and won't want or have the ability to wait for it to be standardized.

I don't really see how this RFC proposes this problem be solved. The RFC seems to presume it is always some single entity in isolation coming up with a new HTTP header or whatnot; this is rarely the case because why would a vendor care about registering something that they only use internally? If I am only using a parameter internally then this whole train of thought is irrelevant because at the end of the day I wouldn't even care about standards compliance at all (IE if I am only talking to myself, I would not care if I was using "compliant STIX" over that channel. Compliance only matters when you're talking to others).

-
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


John-Mark Gurney ---05/16/2016 09:46:25 PM---Terry MacDonald wrote this message on Sun, May 15, 2016 at 09:39 +1000: > The rfc states in appendix

From: John-Mark Gurney <jmg@newcontext.com>
To: Terry MacDonald <terry.macdonald@cosive.com>
Cc: Allan Thomson <athomson@lookingglasscyber.com>, cti-stix@lists.oasis-open.org, Eric Burger <Eric.Burger@georgetown.edu>
Date: 05/16/2016 09:46 PM
Subject: Re: [cti-stix] Custom properties
Sent by: <cti-stix@lists.oasis-open.org>

---

Terry MacDonald wrote this message on Sun, May 15, 2016 at 09:39 +1000:
> The rfc states in appendix b that :
> 
> When it is extremely unlikely that some parameters will ever be
> standardized. In this case, implementation-specific and private- use
> parameters could at least incorporate the organization's name (e.g.,
> "ExampleInc-foo" or, consistent with [RFC4288
> <https://tools.ietf.org/html/rfc4288>], "VND.ExampleInc.foo") or primary
> domain name (e.g., "com.example.foo" or a Uniform Resource Identifier [
> RFC3986 <https://tools.ietf.org/html/rfc3986>] such as "
> http://example.com/foo").

> In my mind I would accept replacing the x_ should with a must, and saying
> that the custom properties must contain the domain name of the organisation
> that invented it.

Even as much as I don't like the reverse order domain name, IMO, for
things like this, it should be used...

I too would prefer a MUST too, but others disagreed.

> I also would like it defined that an unknown field within an object means
> that the unknown fields are ignored, but as much of the object data that is
> known is processed. At the moment it appears to be up to the implementer to
> decide what to do. We should mandate one way.. And my vote is that only the
> unknown field are ignored during processing, but are not discarded. My
> reasoning is that of you are a recipient of an object with an unknown field
> you want to extract as much information out of it that you understand as
> possible, and if you don't understand a little bit of it then that should
> be ok.

I have a feeling that this is what most implementations will do, as if you
can't import someone's STIX, even though it's standards compliant, you'll
get customer complains...

> The problem with this stance is that the implementers need to ensure that
> the whole object is retained to keep the validity of the object (especially
> with future cryptographic validation of authenticity) even though they may
> not understand some of the data they are storing. In my mind this is still
> OK, because of someone is acting as a community hub, you want the data to
> pass through them undisturbed.

I'd think it's up to the implementation to decide if they want to be
able to validate an object's signature after import.  If you aren't
passing the data on, there may not be a need to do any signature
validation after importing into your DB.

-- 
John-Mark

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php