[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] Timestamps - Proposal (UTC)
We essentially, but not explicitly, are. We are 99.999% using the W3C spec, with the proviso that we are specifying the upper and lower bound of decimal seconds to six digits. > On Dec 12, 2015, at 12:16 AM, Jerome Athias <athiasjerome@gmail.com> wrote: > > 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 >> >> >> >>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]