Re: [cti] Motion to open a ballot on the STIX timestamp format

I am OK with that as well.

In that case then the other field would be "timestamp_ns" (?)

-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security| www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown

From: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: Trey Darley <trey@kingfisherops.com>, John-Mark Gurney <jmg@newcontext.com>, "Wunder, John A." <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 12/08/2016 04:14 PM
Subject: Re: [cti] Motion to open a ballot on the STIX timestamp format
Sent by: <cti@lists.oasis-open.org>

I would like to do this, but use microseconds.

A 64bit unsigned Int = 1.8446744 x 10^19
Number of Microseconds in a Year = 31,536,000,000,000 = 3.15 x 10^13

That means a 64bit unsigned Int can hold approximately 584,942 years of time, if my math is correct.

So in normative language we would say for timestamps:

Timestamps in STIX are represented as a number of microseconds since the Unix epoch (January 1, 1970) in the UTC (Coordinated Universal Time) timezone. The JSON MTI serialization uses the JSON number type <TODO: add reference> when representing timestamp.

Requirements
· The timestamp field MUST be a non-negative integer
· A timestamp of 0 represents January 1, 1970 00:00:00.000000 UTC
· All timestamps MUST be in UTC time.

If the timestamp being stored requires sub-microsecond precision, then the precision beyond microseconds MUST be encoded in a second optional property that has a suffix of "_????" (TBD suffix).

Bret

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Sent: Thursday, December 8, 2016 11:46:12 AM
To: Bret Jordan (CS)
Cc: Trey Darley; John-Mark Gurney; Wunder, John A.; cti@lists.oasis-open.org
Subject: Re: [cti] Motion to open a ballot on the STIX timestamp format

What do think of this proposal:

A STIX timestamp is defined as the number of milliseconds that have transpired since January 1, 1970, encoded as a JSON number. If the timestamp being stored requires sub-millisecond precision, then the microsecond portion of the timestamp must be encoded in a second optional property, "timestamp_μs", as a JSON number.

What this accomplishes:

- It allows us to keep the timestamp as a JSON number
- It does not force us down the rabbit hole of prescribing data types, and thus locking some systems and languages out of supporting STIX
- It allows people to encode arbitrarily large timestamps
- It allows people to encode arbitrarily precise timestamps for whatever edge case they think is valid

This is basically how Java both handles microseconds and below - relegate them to another struct (that most people never use).

-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security| www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown

From: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>
To: Trey Darley <trey@kingfisherops.com>, John-Mark Gurney <jmg@newcontext.com>
Cc: "Wunder, John A." <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 12/08/2016 01:39 PM
Subject: Re: [cti] Motion to open a ballot on the STIX timestamp format
Sent by: <cti@lists.oasis-open.org>

So I have been talking with Jason offline to address my concerns. The question I have is given these two levels of subsecond precision, how far in the future will a float64 hold values before it truncates?

1) microseconds
2) picoseconds

A follow-on question is will it always truncate the subseconds first?

The problem I was worried about is:
1) I get a STIX object with a timestamp down to picoseconds or greater.
2) I parse that JSON object so I can order the fields in a certain order so I can compute the digital signature.
3) Since this is a JSON number format and not a JSON string, I will need to probably store this in a "float64" in my struct.
4) So with picoseconds, at what point will that timestamp get truncated? Because if they get truncated, then the digital signature I generate will not match the one you send.

Bret

From: Trey Darley <trey@kingfisherops.com>
Sent: Thursday, December 8, 2016 5:37 AM
To: John-Mark Gurney
Cc: Bret Jordan (CS); Wunder, John A.; cti@lists.oasis-open.org
Subject: Re: [cti] Motion to open a ballot on the STIX timestamp format

On 07.12.2016 16:50:52, John-Mark Gurney wrote:
> Bret Jordan (CS) wrote this message on Wed, Dec 07, 2016 at 18:57 +0000:
> > Based on this discussion, and information we have learned from it,
> > if we keep our current timestamps then we need to add some bounds
> > checking to the number of sub-second digits so as to not break
> > digital signatures.
>
> Can you explain more about this? As timestamps are a text field, I
> do not see how this can break digital signatures.
>

Bret -

Echoing John-Mark and Jason's questions, I also cannot see the impact
on digital signatures. Could you please provide additional background
to help us understand your concerns?

--
Cheers,
Trey
++--------------------------------------------------------------------------++
Kingfisher Operations, sprl
gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D
++--------------------------------------------------------------------------++
--
"Every old idea will be proposed again with a different name and a
different presentation, regardless of whether it works." --RFC 1925

cti message