OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Could we use this profile?
http://www.w3.org/TR/NOTE-datetime



2015-12-07 18:51 GMT+03:00 Eric Burger <Eric.Burger@georgetown.edu>:
> Like I said, works for me. If it was seven days ago, I would be more adamant
> about not turning STIX into the Intel Capital Appreciation Program™. At this
> juncture, just go with it.
>
> On Dec 7, 2015, at 10:48 AM, Jordan, Bret <bret.jordan@BLUECOAT.COM> wrote:
>
> One of the core elements of the proposal is that you MUST include the
> timezone offset.  If this is not sufficient, or we have gone in error,
> please speak up.
>
>
> Thanks,
>
> Bret
>
>
>
> Bret Jordan CISSP
> Director 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."
>
> On Dec 7, 2015, at 08:16, Eric Burger <Eric.Burger@georgetown.edu> wrote:
>
> 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
>
>
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]