Title: Re: [cti-stix] Custom properties
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?
-----Original Message-----
From: John-Mark Gurney []
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
>
> ---------------------------------------------------------------------
> 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
>
>
>
--
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
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.
