OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [cti-stix] Custom properties

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]