RE: [cti] timestamp proposal for STIX 2.0 RC3

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

My goodness guys. What are we even talking
about here? Bounds around what - time itself? What is the upper bound of
time? Heat death of the universe?

I am really starting to feel like there
are some individuals at this point who are arguing for the sake of making
arguments. Come on folks - lets come down to earth. **We ALL** make enterprise
software here (and if you don't then I am not sure why you are wading into
this debate). In any piece of software you have EVER written, when has
a timestamp ever been stored or tested upon internally in any format EXCEPT
either (a) UNIX epoch, or (b) an epoch-derived native time structure? **Exactly
Never** - because this is the format that the UNIX gods cooked up in
the 60s and it is what every single operating system returns when you call
the C standard libraries that every piece of software on the planet relies
on at the root - and this includes NTP, rdate, and all other time daemons
- yes, even these critters rely on epoch at the core.

To the "we need to define boundaries
/ limits / binary data types / etc", I will remind people why we did
not do this for strings. If we FORCE people to encode a time into say a
64 bit integer, then what happens when the system itself does not
provide the ability to test time at that level because it has no access
to it? Does this mean that we want to make it impossible for these devices
or systems to support STIX, simply because they can't test beyond 2037?
This is poppycock. We want as many people to support STIX as possible.
Forcing arbitrary data sizes into the standard is not going to help anyone
(and it is not actually going to help anyone implement anything, because
as I mentioned everyone already has their own time formats).
.
--

"For
example, if you send me a date that has pico-seconds and I can only understand
micro-seconds and thus drop that precision on the floor, then the digital
signatures will FAIL.  "

This makes no sense to me at all, I
would need someone to explain this in more detail. Digital signatures have
to be validated based on the received JSON, not based on whatever data
format you decided to store in your local database. Remember that most
end-recipient folks are going to be taking the JSON, storing it in some
other format, and throwing it away... anyone who wants to re-share CTI
content (IE a TIP) has to store the raw JSON in some fashion, or else the
signature will break. This has nothing to do with timestamps at all.

-
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:      
 "Coderre, Robert"
<rcoderre@verisign.com>
To:      
 "Bret_Jordan@symantec.com"
<Bret_Jordan@symantec.com>, "stefan@hagen.link" <stefan@hagen.link>,
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date:      
 12/07/2016 02:53 PM
Subject:    
   RE: [cti] timestamp
proposal for STIX 2.0 RC3
Sent by:    
   <cti@lists.oasis-open.org>

---

I’m in favor of option #2,
with fallback to option #1.  I am not convinced that epoch is necessary
for our purposes.
 
If we fall on #2 or #4 by
consensus, normative language should include some statement on what the
upper bound is and perhaps to force right-padding of fractional seconds
to help address _some_ of Bret’s concerns.
 
From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org]
On Behalf Of Bret Jordan (CS)
Sent: Wednesday, December 07, 2016 1:38 PM
To: Mr. Stefan Hagen; cti@lists.oasis-open.org
Subject: [EXTERNAL] Re: [cti] timestamp proposal for STIX 2.0 RC3
 
I am not sure which I would prefer between
2 and 4.  But I strongly dislike not giving bounds to numbers.  If
we do this, then all of our digital signatures in the future will probably
break.  For example, if you send me a date that has pico-seconds and
I can only understand micro-seconds and thus drop that precision on the
floor, then the digital signatures will FAIL.  
 
It is such common practice in standards
bodies to not only give guidance but to also give limits and bounds to
content, that I can not see why we would not do this here.  
 
Further, ballots that have results at a
near 50/50 or I would go as far as 60/40 result, are probably saying that
we need to do more work to figure the issue out.  It is my belief
in a standards body that a simple majority is just saying that the community
is radically divided on the issue and we should go back and work to find
a solution that works for the majority of people.
 
Bret

---

From: cti@lists.oasis-open.org<cti@lists.oasis-open.org>
on behalf of Mr. Stefan Hagen <stefan@hagen.link>
Sent: Wednesday, December 7, 2016 11:22:44 AM
To: cti@lists.oasis-open.org
Subject: Re: [cti] timestamp proposal for STIX 2.0 RC3
 
I favour 1, 2, 3, and least 4 of
below alternatives.

Top-postingly,
Stefan.

On 07/12/16 19:04, Wunder, John A. wrote:
> So I’ve been thinking a lot about this and it’s very similar to
the
> debate where we talked about whether we should limit the max lengths
> that strings could be. We ended up deciding not to add that based
on a
> ballot, and while it wasn’t an overwhelming result I think for
> consistency we should continue that pattern here. That would also
be
> consistent with the ISO8601 text, which didn’t have any limits.
> 
>  
> 
> I do think that Andy’s point is good and we should provide
> recommendations for what you should support for string limits, max
> number sizes, time precisions, etc. IMO all of that should go in an
> implementer’s guide.
> 
>  
> 
> If this ends up biting us later we can add the limits as normative
> requirements in a later version. Going down this path would lead to:
> 
>  
> 
>  
> 
> *2.10.  Timestamp*
> 
> Type Name: timestamp
> 
> Timestamps in STIX are represented as a number of seconds 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.
> 
>  
> 
>  
> 
> That text would let you represent the same dates you can represent
in
> the current ISO8601 format, which everyone has been OK with. It would
> mean that different implementations may support different precision,
but
> as the ballot showed people tend to be fine with that and, again,
that’s
> how the old text worked so it’s not even a change.
> 
>  
> 
> Let’s have a quick informal ballot, and depending on how that goes
we
> probably should move to a formal ballot. In order of preference, what
do
> you think:
> 
>  
> 
> 1.       Keep the old ISO8601 format, no limits on
acceptable dates.
> 
> 2.       Keep the old ISO8601 format, but add limits
on acceptable
> precision and date ranges.
> 
> 3.       Use this new epoch format, no limits on acceptable
dates.
> 
> 4.       Use this new epoch format, but add limits
on acceptable
> precision and date ranges.
> 
>  
> 
> I have no preference on this topic. They all seem workable, I just
want
> us to agree on something and move on.
> 
>  
> 
> John
> 
>  ... [8<]