This discussion should now take place in the pre-draft document. Please add comments or changes to timestamps there..
CTI-Common 1.0
Thanks,
Bret Bret Jordan CISSPDirector 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."
I would suggest breaking the precision field set of normative statements into separate lines rather than a paragraph. Personally, I find multiple normative statements in a paragraph much harder to read.
It may be useful to add one or two examples in here as well.
All discrete timestamps (i.e. not time ranges or relative times) in the CTI specifications are made up of two fields:
the timestamp field itself, containing the time, and an optional field that indicates the precision of the timestamp.
The timestamp field MUST be a valid RFC3339-formatted timestamp. As permitted by RFC3339, any number of decimal
fields are permitted in the seconds value. The timestamp itself MUST be represented in the UTC timezone and MUST use the 'Z' designation to indicate this.
The optional precision field, if present, MUST be one of "year", "month", "day", "hour", "minute", or
"second”.
The default value is "second", so omitting the field is equivalent to explicitly specifying "second”.
A value of "second" indicates that the value in the
timestamp field is precise to the number of digits in the seconds value.
A value of “minute”, “hour”, “day”, “month”, or “year”
indicates that the timestamp value is precise to that as a floor.
When specifying a precision other than "second", the
timestamp field MUST contain zeroes for all fields beyond the specified precision.
For example, if the precision field is "month", the
timestamp field must contain "00" for the day, hour, minute, and second fields and the fields indicate a time of that day.
The timestamp precision field is always nested at the same level as the timestamp field. The key name will
be [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”.
Here’s what I put together for normative text. I’m just throwing this out there…any and all criticisms or (even better) edits are welcome.
Also we have nowhere to put this now. What should we do to get a CTI Common specification document rolling?
John
---
All discrete timestamps (i.e. not time ranges or relative times) in the CTI specifications are made up of two fields:
the timestamp field itself, containing the time, and an optional field that indicates the precision of the timestamp.
The timestamp field MUST be a valid RFC3339-formatted timestamp. As permitted by RFC3339, any number of decimal
fields are permitted in the seconds value. The timestamp itself MUST be represented in the UTC timezone and MUST use the 'Z' designation to indicate this.
The optional precision field, if present, MUST be one of "year", "month", "day", "hour", "minute", or "second".
The default value is "second", so omitting the field is equivalent to explicitly specifying "second". A value of "second" indicates that the value in the timestamp field is precise to the number of digits in the seconds value. A value of “minute”, “hour”,
“day”, “month”, or “year” indicates that the timestamp value is precise to that as a floor. When specifying a precision other than "second", the timestamp field MUST contain zeroes for all fields beyond the specified precision. For example, if the precision
field is "month", the timestamp field must contain "00" for the day, hour, minute, and second fields and the fields indicate a time of that day.
The timestamp precision field is always nested at the same level as the timestamp field. The key name will
be [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”.
Good points... I have asked John Wunder to review the text and clean it up. We hope to get some normative text out to this group tomorrow.
Thanks,
Bret
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 Jan 20, 2016, at 14:32, Jane on Travel for CTI-TC < jg@ctin.us> wrote:
Bret & All:
The only thing I would add is the word "/CybOX" after STIX in the first paragraph. I believe we talked about this being part of the Common Core, right? As such, I believe the specification language should call out both standards.
Jane Ginn
CTIN
On 1/20/2016 12:32 PM, Jordan, Bret wrote:
I agree. I would like to motion that we move this out of general debate and move it in to the crafting of normative text. I think the proposal we can all agree on, or that we have general consensus on is:
Timestamps in STIX will use a single RFC3339 timestamp field that includes the "Z" timezone offset (example:
2016-01-20T12:27:53.123456Z). All timestamps MUST be in UTC. Timestamps may include any number of subsection precision. A corresponding text precision field with year, month, day, hour, minute, second (default = second). The values for the precision field
MUST be all lower-case. The precision is interpreted the same as ISO-8601, a floor. The timestamp precision field is optional. A producer recording time from something in US EST time, would need to convert that time to UTC before sending it across the wire.
A timestamp know only to a year would look like:
{
"timestamp": "2016-00-00T00: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 or where the precision is unknown 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",
}
Thanks,
Bret
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."
|