|Nit: I doubt you want this vote to proceed as moved. That would require unanimous consent. Good luck!|
Ignoring that, the proposal is fantastically fine except for the bits about custom properties. You might think “wow! email uses lots of X-mumbles, and even RFC 822 back in 1982 specified the use of X-mumble for proprietary email headers. The problem is, in fact, that explosion of X-mumbles that ended up becoming standards. They became standards because people experimented and the experiments succeeded. The problem is the success bred standards. The real problem is all of those people who did the experimenting were stuck with implementations that knew X-mumble, and had no incentive to rewrite their working code to do mumble.
What to do? Best world is to maintain a registry with first-come first-serve, no documentation requirements. That avoids collisions, encourages registration, and makes for seamless transitions to people adopting the experiments that succeed. True, it means that reallyGoodCustomFieldName
can get assigned and never used when the experiment fails. That is a tiny price to pay to avoid the reality of all of our standardized
fields in the future starting with x_
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
Thanks to some suggestions by Allan Thompson we have some good language nailed down for timestamp, timestamp precision, and custom properties. Given that, the recent agreement on the working call, and a lack of further comments I’d like to make a motion:
I motion that the STIX SC accept by unanimous consent the timestamp, timestamp precision, and custom properties text contained in the STIX pre-draft specifications and duplicated below, and that the SC allow the STIX editors to move these sections to DRAFT
status. If after a period of 5 business days we don’t hear any substantive (non-editorial) objections we will move it from REVIEW to DRAFT.
section defines the timestamp
type. Most discrete timestamps (i.e. not time ranges or relative times) in STIX have a corresponding optional field that indicates the precision of the timestamp, of type
In cases where the timestamp is metadata about the STIX construct, such as creation and modification times for STIX top-level objects, the timestamp will not have the corresponding precision field. In these cases, the precision is "full".
timestamp field MUST
be a valid RFC 3339-formatted timestamp.
be represented in the UTC timezone and MUST
use the 'Z' designation to indicate this.
optional precision field, if present, MUST
a value from the timestamp-precision
default value for the precision field is "full", so omitting the field is equivalent to explicitly specifying "full".
value of "full" indicates that the value in the timestamp field is precise to the full number of digits in the timestamp value (including any fractional seconds, such as milliseconds or microseconds).
value of “minute”, “hour”, “day”, “month”, or “year” indicates that the timestamp value is precise to that as a lower bound (the precision window is the timestamp value plus one unit of the precision value). For example, if the timestamp value is 2016-04-25T13:00:00Z
and the precision value is "hour", the time is greater than or equal to 2016-04-25T13:00:00Z and less than 2016-04-25T14:00:00Z.
specifying a precision other than "full", the time portion of the timestamp field
contain zeroes for all fields beyond the specified precision while the date portion MUST contain "01" for all fields beyond the specified precision.
example, if the precision field is "month", the timestamp field must contain "01" for the day field and "00" for the hour, minute, and second fields such as 2016-12-01T00:00:00Z.
timestamp precision field is always nested at the same level as the timestamp field.
property name for the precision field is [timestamp_field_name]_precision.
timestamp known only to a year would look like:
timestamp known only to an hour would look like:
timestamp known to a second would look like:
timestamp known to 5 digit sub second precision would look like:
represents the precision options for a given timestamp. Its value MUST
one of "year", "month", "day", "hour", "minute", or "full”.
authors of this specification recognize that there will be cases where certain information exchanges can be improved by adding fields that are not specified nor reserved in this document; these fields are called
This section provides guidance and requirements for how producers can use Custom Properties and how consumers should interpret them in order to extend STIX in an interoperable manner.
create any number of Custom Properties in a STIX TLO.
start with “x_” followed by a source unique identifier (like a domain name), an underscore and then the name. For example:
Property keys SHOULD
have a minimum length of 3 characters (including the prefix) and a maximum length of 30 characters.
Property keys MUST
not be longer than 256 characters.
Properties that are not prefixed with “x_” may be used in a future version of the specification for a different meaning. If compatibility with future versions of this specification is required, the “x_” prefix
be uniquely named when produced by the same source and SHOULD
use a consistent namespace prefix (e.g., a domain name).
be used when there is no existing field defined by the STIX specification that fulfills that need.
consumer that receives a STIX document with one or more Custom Properties
the properties in the manner intended by the producer, if known
to process the document further
ignore non-understood properties and continue processing the document
reporting and logging of errors originating from the processing of Custom Properties depends heavily on the technology used to transport the STIX document and is therefore not covered in this specification.
that receive a STIX TLO that contains one or more Custom Properties that are understood
process the Custom Properties according to the rules for that Custom Property.
of STIX documents that contain Custom Properties should be well aware of the variability of consumer behavior depending on whether or not the consumer understands the Custom Properties present in a STIX TLO. Rules for processing Custom Properties should be
well defined and accessible to any consumer that would be reasonably expected to parse them.