[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 <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 > > > -- John-Mark
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]