OASIS Cyber Threat Intelligence (CTI) TC

In consideration of the fact that the interminable timestamp discussion has resurfaced without a clear end in sight, in the interest of releasing STIX 2.0 in a timely fashion, I hereby motion to open a ballot to keep STIX timestamps exactly as currently defined in the RC3 draft specification. Furthermore, as there appears to be strong consensus within the TC that we should lifeboat timestamp precision as currently defined in the RC3 draft specification, I motion to remove timestamp precision but reserve the 'timestamp-precision' keyword for future use. Can I get a second to the motion? -- Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- "All systems, regardless of composition, do one of three things: blow up, oscillate, or stay about the same." --anonymous Attachment: signature.asc Description: Digital signature

I second this. The current approach is workable and we should move on to more important topics. On 12/7/16, 1:47 PM, "Trey Darley" <cti@lists.oasis-open.org on behalf of trey@kingfisherops.com> wrote: In consideration of the fact that the interminable timestamp discussion has resurfaced without a clear end in sight, in the interest of releasing STIX 2.0 in a timely fashion, I hereby motion to open a ballot to keep STIX timestamps exactly as currently defined in the RC3 draft specification. Furthermore, as there appears to be strong consensus within the TC that we should lifeboat timestamp precision as currently defined in the RC3 draft specification, I motion to remove timestamp precision but reserve the 'timestamp-precision' keyword for future use. Can I get a second to the motion? -- Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- "All systems, regardless of composition, do one of three things: blow up, oscillate, or stay about the same." --anonymous

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. I am against using a ballot at this stage of the debate. So I motion against a ballot until we have a clearer direction on what we should do.   Bret From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Wunder, John A. <jwunder@mitre.org> Sent: Wednesday, December 7, 2016 11:51:57 AM To: Trey Darley; cti@lists.oasis-open.org Subject: Re: [cti] Motion to open a ballot on the STIX timestamp format   I second this. The current approach is workable and we should move on to more important topics. On 12/7/16, 1:47 PM, "Trey Darley" <cti@lists.oasis-open.org on behalf of trey@kingfisherops.com> wrote:     In consideration of the fact that the interminable timestamp     discussion has resurfaced without a clear end in sight, in the     interest of releasing STIX 2.0 in a timely fashion, I hereby motion to     open a ballot to keep STIX timestamps exactly as currently defined in     the RC3 draft specification. Furthermore, as there appears to be     strong consensus within the TC that we should lifeboat timestamp     precision as currently defined in the RC3 draft specification, I     motion to remove timestamp precision but reserve the     'timestamp-precision' keyword for future use.         Can I get a second to the motion?         --     Cheers,     Trey     ++--------------------------------------------------------------------------++     Kingfisher Operations, sprl     gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4  5B9B B30D DD6E 62C8 6C1D     ++--------------------------------------------------------------------------++     --     "All systems, regardless of composition, do one of three things: blow     up, oscillate, or stay about the same." --anonymous    

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. -- John-Mark

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 Attachment: signature.asc Description: Digital signature

So I have been talking with Jason offline to address my concerns.   The question I have is given these two levels of subsecond precision, h ow 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

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

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

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

Yes.  Or some other "defined" suffix that we all decide on. So for the majority of use cases there nothing beyond a microsecond is ever needed, this will just work.  It will be a number, it will be based off of UNIX epoch.  Seems like a great solution.  Then for those people that really want to dabble in nano seconds or pico seconds, they can use a custom property with the suffix name we define to store any extra precision.   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 1:27:24 PM 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   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

Bret Jordan (CS) wrote this message on Thu, Dec 08, 2016 at 17:39 +0000: > 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. Except that as Trey and others pointed out, the current timestamp format is a string, not a number, so this does not apply. Yes, the current proposal is to use a number, but that was not what you were replying to. > 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? -- John-Mark

On 8 December 2016 at 00:50, John-Mark Gurney < jmg@newcontext.com > 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. As long as nobody adds redundant zeroes to the end, it should be fine, I think.   -- John-Mark ------------------------------ ------------------------------ --------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/ apps/org/workgroup/portal/my_ workgroups.php -- Dave Cridland phone   +448454681066 email   dave.cridland@surevine.com skype   dave.cridland.surevine Participate Collaborate Innovate Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND If you think you have received this message in error, please notify us.