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] Motion to move timestamp, timestamp precision, and custom properties to draft status

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.

See BCP 178 / RFC 6648.

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_.

On May 5, 2016, at 3:17 PM, Jordan, Bret <bret.jordan@BLUECOAT.COM> wrote:




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." 

On May 5, 2016, at 12:39, Wunder, John A. <jwunder@mitre.org> wrote:

Hi everyone,

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.



​4.8.​ Timestamp

Type Name: timestamp
Status: Review
MVP: Yes

This 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 timestamp-precision. 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".

​4.8.1.​ Format


  • The timestamp field MUST be a valid RFC 3339-formatted timestamp.
  • The timestamp MUST be represented in the UTC timezone and MUST use the 'Z' designation to indicate this.
  • The optional precision field, if present, MUST a value from the timestamp-precision enumeration.
    • The default value for the precision field is "full", so omitting the field is equivalent to explicitly specifying "full".
    • A 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).
    • A 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.
    • When specifying a precision other than "full", the time portion of the timestamp field MUST contain zeroes for all fields beyond the specified precision while the date portion MUST contain "01" for all fields beyond the specified precision.
      • For 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.
  • The timestamp precision field is always nested at the same level as the timestamp field.
  • The property name for the precision field is [timestamp_field_name]_precision.
    • For example, if the key of the timestamp field is “created_at”, the key of the precision field is “created_at_precision”.

​4.8.2.​ Examples

A timestamp known only to a year would look like:
 "timestamp": "2016-01-01T00:00:00Z",
 "timestamp_precision": "year"

A timestamp known only to an hour would look like:
 "timestamp": "2016-01-20T12:00:00Z",
 "timestamp_precision": "hour"

A timestamp known to a second would look like:
 "timestamp": "2016-01-20T12:31:12Z"

A timestamp known to 5 digit sub second precision would look like:
 "timestamp": "2016-01-20T12:31:12.12345Z"

​4.9.​ Timestamp Precision

Type Name: timestamp-precision
Status: Review
MVP: Yes

A timestamp-precision represents the precision options for a given timestamp. Its value MUST be one of "year", "month", "day", "hour", "minute", or "full”.


​5.1.​ Custom Properties

Status: Review
MVP: Yes

The 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 Custom Properties. 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.

​5.1.1.​ Requirements

  • Producers MAY create any number of Custom Properties in a STIX TLO.
  • Custom Properties SHOULD start with “x_” followed by a source unique identifier (like a domain name), an underscore and then the name.  For example: x_examplecom_customfield.
  • Custom Property keys SHOULD have a minimum length of 3 characters (including the prefix) and a maximum length of 30 characters.
  • Custom Property keys MUST not be longer than 256 characters.
  • Custom 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 MUST be used.
  • Custom Properties SHOULD be uniquely named when produced by the same source and SHOULD use a consistent namespace prefix (e.g., a domain name).
  • Custom Properties SHOULD only be used when there is no existing field defined by the STIX specification that fulfills that need.

Any consumer that receives a STIX document with one or more Custom Properties MAY:
  • process the properties in the manner intended by the producer, if known
  • refuse to process the document further
  • silently ignore non-understood properties and continue processing the document

The 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.

Consumers that receive a STIX TLO that contains one or more Custom Properties that are understood MUST process the Custom Properties according to the rules for that Custom Property.

Non-Normative: Producers 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.

​5.1.2.​ Examples

 "x_acmeinc_scoring": {
   "impact": "high",
   "probability": "low"

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

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