Re: [cti-stix] Timestamps - Proposal (UTC)

[Eric Burger <Eric.Burger@georgetown.edu>]

It’s a case of balancing “perfection is the enemy of the good” and “learn from other people’s mistakes.” Especially, if the mistakes were made by us.

In 2000, I would not expect a protocol or data format to be in anything other than UTC. In 2015, I cannot imagine anything else. Note that SMTP comes close - if your definition of “local time zone” is “2015-12-07T10:10:53.543000-05:00”, then realize you are ALREADY in UTC.

Given that is the proposal agreed to, I’ll shut up. So long as the text points this out. Namely, that the generator of the timestamp is responsible for calculating the offset.

The ironic thing is I will bet 99.9% of the generators use UTC internally and will convert to local time, to which someone will write code to format it into ASCII, where the repository will receive the ASCII time string, convert it to a time, and then apply the presented offset from UTC (-5h in this example) to regenerate the original UTC.

I think I need to buy more Intel stock ;-)

> On Dec 7, 2015, at 7:21 AM, Trey Darley <trey@soltra.com> wrote:
> 
> On 06.12.2015 08:16:45, Eric Burger wrote:
>> If the goal is to work with a standard that works everywhere in the
>> world and is immune to local, flavor of the day definitions of
>> “local time,” the *ONLY* option is UTC. The world cannot agree to a
>> single repository to lookup what local time is. The Internet
>> community has put one up on a volunteer basis, but it explicitly
>> states that it is not normative, may be wrong, and will almost
>> certainly be out of date.
>> 
> 
> Hi, Eric -
> 
> On a technical level, I agree with you 110%. But as the timestamp
> discussion was approaching Tolstoy's "War and Peace" in terms of
> wordcount, in the interest of achieving consensus I agreed with
> supporting multiple timezones.
> 
> In your view, is the potential downside of *not* making UTC mandatory
> *so* detrimental as to justify reopening this debate, or can we live
> with the current consensus?
> 
> -- 
> Cheers,
> Trey
> --
> Trey Darley
> Senior Security Engineer
> 4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430
> Soltra | An FS-ISAC & DTCC Company
> www.soltra.com
> --
> "There's never enough time. Thank you for yours." --Dan Geer

Attachment: smime.p7s
Description: S/MIME cryptographic signature