My understanding is that we had consensus for 1) UTC, 2) the need for time zone, 3) a desire to not have a separate field for time zone, and 4) a separate timestamp_precision
field to handle fine grained precision (e.g. nanoseconds).
Therefore, if we relegate the
Temporal Interval discussion to a dot release as Patrick suggested, and not the midsummer MVP target—assuming Eric doesn’t end up with game-breaking objections, do we not have consensus on the following?
The "timestamp" field in STIX, CybOX, and TAXII MUST use an RFC 3339 compliant timestamp that includes a timezone offset from UTC or the value is in UTC with a "Z". Examples:
2016-01-18T11:10:10-04:00
2016-01-18T11:10:10.123456-04:00
Joey
--
Joey Peloquin, Senior
Manager
Citrix Security
| Threat Intelligence and Vulnerability
Management
Citrix Systems, Inc.
| 851 West Cypress Creek Road
| Fort Lauderdale, FL 33309
m
(817) 412-0475 |
o (954) 229-5649
|
e joey.peloquin@citrix.com
From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org]
On Behalf Of Jordan, Bret
Sent: Monday, January 18, 2016 11:21 AM
To: Struse, Richard
Cc: cti@lists.oasis-open.org
Subject: [cti] Re: Timestamps, yet again
So requiring the timestamps to be in UTC is divergent from RFC 3339. RFC 3339 requires that times be derived off of UTC, which is what I think we all want. Meaning you can NOT do this:
2016-01-18T11:10:10 and expect people to think that it is EDT. That would and should FAIL. You would need to do:
2016-01-18T11:10:10-04:00 for EDT or you could do 2016-01-18T15:10:10Z / 2016-01-18T15:10:10+00:00
I think if we are going to go down the path of RFC 3339, regardless of my previous comments, we should just use it as is. This will hopefully guarantee that libraries will work.
The "timestamp" field in STIX, CybOX, and TAXII MUST use an RFC 3339 compliant timestamp that includes a timezone offset from UTC or the value is in UTC with a "Z". Examples:
2016-01-18T11:10:10-04:00
2016-01-18T11:10:10.123456-04:00
This means you can include as many or as few fractional sections as you want.
The "timestamp_precision" field will be at the same level as the "timestamp" field and will be optional. The default precision is Microseconds. This field in JSON is a string field and has the following valid options in the ENUM:
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
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."
The more I thought about this the more my thinking was driven by what various datetime libraries allow the developer to do. While in a perfect world I’d prefer
the ISO 8601 “just specify what you know” (which allows 2016-01-01 for example to say January 1, 2016), libraries that support 8601 don’t seem to give the developer any way of distinguishing between “2016-01-01” and “2016-01-01T00:00:00.0Z”. Therefore, we’re
better off going with RFC 3339 which mandates a full date/time and the separate precision specifier we’ve previously discussed. As far as fractional seconds, I say we allow zero or more digits – the libraries support that, it’s compliant with RFC 3339 and
at the F2F no one could articulate a reason why that was a burden to implementers.
All times expressed in UTC (“Z”)
Separate precision specifier
Thoughts??? We really need to decide this. This along with IDs are the next major things we need to resolve and resolve SOON.
Director of Security Architecture and Standards | Office of the CTO
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."
As this issue was brought up at the Face2Face, and thus reopened for debate and consensus, and the consensus today was leaning toward the use of RFC3339 as is, without further stipulation and the removal of timestamp_precision field, I
thought it would be best to re-read the RFC for clarification.
Section 4.2. Local Offsets
Allows for local time, so long as it is an offset from UTC
1996-12-19T16:39:57-08:00
I do not see anything in RFC3339 that allows for dates/times with less precision than a fully qualified timestamp: yyyymmddThh:mm:ssZ
ISO8601 does explicitly allow for reduced precision by just truncating the value.
From my understanding of the community we have the following requirements:
1) Represent reduced precision
2) Represent an arbitrary number of fractional sections
3) Represent values in local time as a offset to UTC or in UTC
20150114T23:21:20.123456Z
20150114T23:21:20.123456-08:00
Director of Security Architecture and Standards | Office of the CTO
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."
|