OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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


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





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