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] Re: STIX motion of unanimous consent


John,

Yes, the direction you're going with Number sounds good.


Does "requires the use of UUIv4" mean "the computer has to generate it and it cannot be manually created"? My main concern about IDs is that they could be hand-crafted, and thus more likely to collide (by accident or on purpose, if a malicious actor wants to play havoc).


Thanks,

John


From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Wunder, John A. <jwunder@mitre.org>
Sent: Friday, June 3, 2016 8:14:51 AM
To: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Re: STIX motion of unanimous consent
 

Hey John,

 

It’s never too late for comments, we want to make sure to get this right.

 

-          Number: Yeah, agreed, this is important info…I’m kind of coming around to the idea of including a very short JSON binding specification where we can put text like this. I’d leave it out of the primary spec though, which should be more format-neutral and concise.

-          IDs: I think we’re covered on this point because IDs are of type “identifier”, which requires the use of UUIDv4.

 

Does that work for you?

 

John W.

 

From: <cti-stix@lists.oasis-open.org> on behalf of John Anderson <janderson@soltra.com>
Date: Friday, June 3, 2016 at 7:56 AM
To: Aharon Chernin <achernin@soltra.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Re: STIX motion of unanimous consent

 

A couple comments, if I'm not too late.

 

Number

The JSON number format explicitly:

1. Allows exponential notation (which we may want to mention) and

2. Disallows quoted values (strings).

 

Also, it does not support any imaginary or complex numbers, which may/may not be worth mentioning.

Here's one link that has more detail: http://spacetelescope.github.io/understanding-json-schema/reference/numeric.html#number

 

Ids:

The phrase "globally unique identifiers" could be problematic, unless the spec specifies how those IDs are guaranteed to be globally unique. I'm not exactly sure what normative wording would be better, but here's a rough stab at it:

 

While it is infeasible to guarantee/enforce that IDs are truly globally unique, Object Creators MUST use their best effort to avoid creating duplicate IDs. This best-effort approach includes generating IDs using algorithms with low collision potential (such as UUID) and eschewing manual creation of IDs, especially by copy-and-paste.

 

If these comments come too late in the process or would produce otherwise avoidable churn, please feel free to ignore them.

Sincerely,

John Anderson

 


From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Aharon Chernin <achernin@soltra.com>
Sent: Friday, June 3, 2016 7:16:30 AM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] STIX motion of unanimous consent

 

I motion that the STIX SC accept by unanimous consent the Boolean, List, Number, IDs and References, and Object Creator text contained in the STIX pre-draft specifications and duplicated below, and that the SC allow the STIX editors to move these sections to CONSENSUS status. If after a period of 5 business days we don’t hear any substantive (non-editorial) objections we will move these sections from REVIEW to CONSENSUS.

 

​3.1.​ Boolean

Type Name: boolean

Status: Review

MVP: Yes

 

A boolean contains a value of either true or false. Properties with this type MUST have a value of true or false.

 

The JSON MTI serialization uses the JSON boolean type, which is a literal (unquoted) true or false.

​3.1.1.​ Examples

{

 ...

 "is_directional": true,

 ...

}

 

3.6.​ List

Type Name: list

Status: Review

MVP: Yes

 

A list contains an ordered sequence of values. When the phrasing “list of type <type>” is used, all values in the list MUST be of the specified type. For instance, list of type number means that all values of the list must be of the number type. Upper and lower bounds of the list – the minimum and maximum number of elements -– may be specified where the list is used. This section does not specify the upper and lower bounds of list.

 

The JSON MTI serialization uses the JSON array type, which is an ordered list of zero or more values.

 

​3.6.2. Examples

{

 ...

 "observation_refs": [

   "observation--b67d30ff-02ac-498a-92f9-32f845f448cf",

   "observation--c96f4120-2b4b-47c3-b61f-eceaa54bd9c6",

   "observation--787710c9-1988-4a1b-9761-a2de5e19c62f"

 ]

 ...

}

 

3.7.​ Number

Type Name: number

Status: Review

MVP: Yes

 

A number contains any number that can be expressed as a real number (e.g., -10, 0, 10, 10.1, 10.123213). Each use of number specifies the following:

 

?         The valid range of values;

?         Whether it is limited to integers or not; and

?         The maximum number of decimal places, if non-integer values are permitted.

 

In the JSON MTI serialization, numbers are represented by the JSON number type.

​3.7.1.​ Examples

{

 ...

 "count": 8,

 ...

}

​6.2.​ IDs and References

Status: Review

MVP: Yes

 

The id field uniquely identifies a TLO series. It MUST conform to the identifier type.

 

The STIX language makes use of globally unique identifiers as defined by the identifier type for all TLOs. The identifier type is also used to define fields that are ID references to other constructs (such as the created_by_ref field in all TLOs). Resolving an ID reference is the process of identifying and obtaining the actual object referred by the ID reference field. ID references resolve to an object when the value of the ID reference field (e.g. created_by_ref) is an exact match with the id field of another object. ID references MAY refer to objects to which  the consumer may not currently have access.

 

​6.3.​ Object Creator

Status: Review

MVP: Yes

 

The identifier of the object creator is stored in the created_by_ref field, capturing the identity of the creator. The object creator is the entity (e.g. system, organization, instance of a tool) that generates the id field for a given object.


Entities that re-publish a TLO from another entity without making any changes to the TLO, and thus maintaining the original id, are not considered the object creator and MUST NOT change the created_by_ref field. Entities that accept objects and republish them with modifications or omissions MUST create a new id for the object and update the created_by_ref field to reflect their Identity as they will be considered the object creator of the new object.

 



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