Re: [cti-users] Timestamp sub-second precision

[Allan Thomson <athomson@lookingglasscyber.com>]

Not all use cases require or capable of that precision.

 

Its also true that some higher level intelligence you only require day or hour accuracy where as the more real-time intelligence objects likely you want very accurate (or as accurate as you can get) from milliseconds.

 

Allan

 

From: "cti-users@lists.oasis-open.org" <cti-users@lists.oasis-open.org> on behalf of Stephen Russett <stephen@digitalstate.ca>
Date: Friday, April 12, 2019 at 1:10 PM
To: "cti-users@lists.oasis-open.org" <cti-users@lists.oasis-open.org>
Subject: Re: [cti-users] Timestamp sub-second precision

 

What was the original reason to accept variations in digits?  Why is it not just set at 3 digits?

 

Steve

 

 

---

From: Allan Thomson <athomson@lookingglasscyber.com>
Sent: Friday, April 12, 2019 12:16 PM
To: jordan2175@gmail.com
Cc: Stephen Russett; cti-users@lists.oasis-open.org
Subject: Re: [cti-users] Timestamp sub-second precision

 

Yup. This is one of the challenges of digital signatures based on original content because this requirement forces many systems to not only ingest/export from their own internal formats and *also* keep the original content.

 

I see this is one of the reasons why the digital signature approach purely on the textual content is flawed and wont work for all use cases.

 

Allan Thomson

CTO (+1-408-331-6646)

LookingGlass Cyber Solutions

 

From: Bret Jordan <jordan2175@gmail.com>
Date: Friday, April 12, 2019 at 8:54 AM
To: Allan Thomson <athomson@lookingglasscyber.com>
Cc: Stephen Russett <stephen@digitalstate.ca>, "cti-users@lists.oasis-open.org" <cti-users@lists.oasis-open.org>
Subject: Re: [cti-users] Timestamp sub-second precision

 

The one thing to be mindful of is, when we do digital signatures, the number of digits cannot change, if you were to retransmit the data.  Otherwise the signature will break. 

 

Thanks,

Bret

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 Apr 12, 2019, at 8:37 AM, Allan Thomson <athomson@lookingglasscyber.com> wrote:

 

Provided the timestamp value is not changed or loses accuracy I donât see any problem generating a new string value for the timestamp.

 

The primary reason for the text is to ensure you donât end up losing precision/accuracy.

 

So *not* .133Z becomes .1Z. That would be a loss of precision and should *not* occur.

 

Regards

 

Allan

 

From: "cti-users@lists.oasis-open.org" <cti-users@lists.oasis-open.org> on behalf of Stephen Russett <stephen@digitalstate.ca>
Date: Friday, April 12, 2019 at 7:31 AM
To: "cti-users@lists.oasis-open.org" <cti-users@lists.oasis-open.org>
Subject: [cti-users] Timestamp sub-second precision

 

Hi all

 

For all time stamps / dates, the spec says that sub second precision is optional and when used, can be 1 to 3 digits. 

 

Is it expected that a parser maintain the digit count? Or can the parser return a standard 3 digit output regardless of the original source sub second count provided. 

 

Example:

 

If you parsed a date with the end have subsecond being .100Z vs something like .1Z: if the parser excepted both, but when the parser converts back to JSON, is it expected to use the original digit count? Where the second example would return .1Z rather than .100Z?  

 

If it is expected to keep the digit count originally used by the source Json string, can you please explain the specific reasons for this.

 

Thanks.