| Completely agree. I would vote in favor of just milliseconds for now as I doubt many things can keep nanosecond level resolution. If in the future we figure out that most devices can use nanosecond resolution we will just add it then.
Lets NOT over engineer the cart before we figure out how to get a horse, more less train it well enough to hook it up to said cart.
Thanks,
Bret Bret Jordan CISSPDirector of Security Architecture and Standards | Office of the CTO Blue Coat Systems 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."
To be clear, nanoseconds would not be a *capability* - it would be mandatory.
All timestamps should follow the exact same mandatory format. Having optional different representations of things, is why STIX is so complicated and we have agreed to move away from that direction. Surely, for something as simple as a timestamp, we can make some progress here and all agree on one mandatory format....
If nanoseconds is optional, then you are creating a large parsing load (instead of parsing a million timestmap fields 1 way, I need to attempt it 2/3/4... n ways) for clients for no good reason. It would be vastly preferred if everyone include nanoseconds and simply zero them out if they can't produce them or they're not relevant.
On the other hand, if people think this is silly because hardly anyone can produce nanoseconds, then we should drop nanoseconds and only include milliseconds in the mandatory format until such a time. Whatever is chosen it should be *mandatory* not an option. The fact that timestamps sometimes include MS and sometimes do not is a large reason I kicked this thread off in the first place.
-
Jason Keirstead
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
<graycol.gif>Tony Rutkowski ---11/23/2015 11:42:05 AM---You want UTC, not GMT (unless you're just implementing it in the UK).
From: Tony Rutkowski <tony@yaanatech.com>
To: Jason Keirstead/CanEast/IBM@IBMCA, Trey Darley <trey@soltra.com>
Cc: "Barnum, Sean D." <sbarnum@mitre.org>, Patrick Maroney <Pmaroney@Specere.org>, Jerome Athias <athiasjerome@gmail.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John A." <jwunder@mitre.org>
Date: 11/23/2015 11:42 AM
Subject: Re: [cti-stix] STIX timestamps and ISO 8601:2000
You want UTC, not GMT (unless you're just
implementing it in the UK).
This proposal just states that the timestamps
should have a capability to express nanosecond
precision. That's quite different than implementing
the capability. For implementations, you want to
express the capability in terms of "uncertainty."
In addition, no one has said anything about the
use of trust mechanisms such as certs.
--tony
On 2015-11-23 10:23 AM, Jason Keirstead wrote:
> So, the proposal is that all timestamps should be RFC3339 with
> nanosecond precision, in GMT. Does anyone have an argument against this?
|