Title: Re: [cti-stix] Custom properties
Great point... Forgive my distrust, I've been out in the left field of "schema on demand" for a while. I certainly empathize with having to look up one field in an object to process another.
Alex
-----Original Message-----
From: John-Mark Gurney []
Sent: Wednesday, May 18, 2016 01:48 PM Central Standard Time
To: Foley, Alexander - GIS
Cc: 'Jason Keirstead'; 'Terry MacDonald'; 'Allan Thomson'; ''; 'Eric Burger'
Subject: Re: [cti-stix] Custom properties
Foley, Alexander - GIS wrote this message on Wed, May 18, 2016 at 02:10 +0000:
> Is namespacing properties really a good idea?
>
> How many different MTA security providers need to put their name in front of _score or _action for it to mean the same thing?
If once _score is an integer from 1 through 100, and another is a
string, and a third is an object, and a fourth is 1 through 10, then
yes, having a name space will help prevent colissions and
misunderstanding.. Having to check the created_by_ref field to decide
how to decide how to understand a field isn't IMO a good method...
> -----Original Message-----
> From: John-Mark Gurney [<mailto:>]
> Sent: Tuesday, May 17, 2016 04:11 PM Central Standard Time
> To: Jason Keirstead
> Cc: Terry MacDonald; Allan Thomson; ; Eric Burger
> Subject: Re: [cti-stix] Custom properties
>
>
> Jason Keirstead wrote this message on Tue, May 17, 2016 at 16:17 -0300:
> > I am still not sure of this "domain name" syntax. Say IBM and Newcontext
>
> I think that's partly why it's a SHOULD now, and not a must...
>
> > 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
>
> Part of having one domain is that you'd at least (hopefully) know who to
> talk to if you received a document w/ it in it and want to try to use it...
>
> It was also added as a way to try to prevent duplication, where two different
> companies w/o talking to each other added x_decay, and now you have a
> conflict...
>
> > 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.
>
> If they can't agree on which domain name, (or register a new one for
> branding), I doubt that the collaboration will last that long.. :)
>
> > 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
>
> The RFC is a first come, first serve... If I'm the first one to register
> decay, then I get to define it my way.. and if someone else wants decay,
> they'll have to pick another name, like decay1, or decay_rate, etc.
>
> This also means that if a registry is used, that if we want to be forwards
> compatible (2.0 docs work w/o modification on 2.1), that we won't be able
> to repurpose any fields that are registered, which restricts what the TC
> can do in the future...
>
> > 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).
>
> Exactly... If you're using it internally, you probably aren't using STIX
> to pass the information around... STIX in an inter-product or
> inter-organization exchange format...
>
> > From: John-Mark Gurney <>
> > To: Terry MacDonald <>
> > Cc: Allan Thomson <>,
> > , Eric Burger
> > <>
> > Date: 05/16/2016 09:46 PM
> > Subject: Re: [cti-stix] Custom properties
> > Sent by: <>
> >
> >
> >
> > 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
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.
