[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Re: [EXT] Re: [cti] Items Ready for TC Wide Final Review
|
This TC has an enormous amount of baggage around a few topics like IDs and Timestamps. These topics have caused significant debate over the years and in most case have even resulted in ballots. We have never had unanimity on these issues, but have achieved consensus and even achieved super majority ballot status [1].
Just because a few people are now suggesting and wanting once again that we go back and make radical changes does not invalidate the ballots that were done previously. We balloted on these concepts and ideas.
Further, I have yet to see anyone bring up an issue that was not previously discussed and debated. All of these issues are not new and the TC made a conscious choice on some of these issues.
We tried to relax the STIX ID a bit, to address some significant issues that were brought up. However, to go back completely on formal consensus and a TC ballot would require at least another ballot that probably archives the same level of pass rate.
These topics come up over and over and over again. We will always have someone that does not like the way something is done. I really worry that if we re-open this debate at this time, that STIX 2.1 will never ship. But it is obviously a TC issue and the TC can decide to once again reopen this debate. But I would strongly encourage us to be careful.
It would also be imprudent to make significant changes without going back through and address the hundreds or thousands of emails and tens of thousands of slack message and issues that were discussed previously. There is a reason why the TC made these decisions.
So my recommendation is, if you want to continue to push this issue and reopen the debate, please address all previously identified issues and concerns from the 6+ months long debate we had. Further, you will need to get a ballot opened and achieve a majority or the TC may say you need to achieve the same level of pass rate we had before.
[1] - https://www.oasis-open.org/apps/org/workgroup/cti/ballot.php?id=2932
Bret
From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Sent: Monday, April 29, 2019 12:17:22 PM To: Piazza, Rich Cc: Alexandre Dulaunoy; cti@lists.oasis-open.org; Patrick Maroney; Sean Barnum Subject: [cti] Re: [EXT] Re: [cti] Items Ready for TC Wide Final Review I personally just don't see why we are messing with this. If we had not done this in the 2.0 spec then all of this debate could have been avoided in the first place.
There could be solid use cases for network equipment makers to use Version 1 UUIDs when generating STIX - we don't know. RFC is RFC, and it is interoperable as it is, I don't see why we would mess with it. - Jason Keirstead Lead Architect - IBM Security Connect www.ibm.com/security "Would you like me to give you a formula for success? It's quite simple, really. Double your rate of failure." - Thomas J. Watson From: "Piazza, Rich" <rpiazza@mitre.org> To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Sean Barnum <sean.barnum@FireEye.com> Cc: Alexandre Dulaunoy <Alexandre.Dulaunoy@circl.lu>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Patrick Maroney <pmaroney@darklight.ai> Date: 04/29/2019 03:09 PM Subject: Re: [EXT] Re: [cti] Items Ready for TC Wide Final Review How about:
The UUID portion SHOULD be generated according to the algorithm(s) defined in RFC 4122, section 4.4 (Version 4 UUID) or section 4.3 (Version 5 UUID) but any algorithm defined in section 4 MAY be used. [RFC4122]
From:
<cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
I agree with this text.
+1
Sean Barnum Principal Architect FireEye M: 703.473.8262 E: sean.barnum@fireeye.com From:
<cti@lists.oasis-open.org> on behalf of Patrick Maroney <pmaroney@darklight.ai>
Here’s a little word crafting for Alexandre’s suggestion:
All identifiers, excluding those used in the deprecated cyber observable container, MUST follow the form object-type--UUID, where object-typeis the exact value (all type names are lowercase strings, by definition) from the typeproperty of the object being identified or referenced and where the UUIDis an RFC 4122-compliant UUID. The UUID MUST be generated according to the algorithm(s) defined in RFC 4122, [RFC4122].
Patrick Maroney DarkLight Mobile: (609)841-5104 Email: patrick.maroney@darklight.ai
From:
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of Alexandre Dulaunoy <Alexandre.Dulaunoy@circl.lu>
On 25/04/2019 22:12, Bret Jordan wrote: All, The following sections are ready for TC final review. Some of these are in different Google Documents so I have included direct links for you. Please have all suggestions and changes in the documents by end-of-day Friday May 10th (2 weeks from today): Introduction and Overview: Section 1.6 - 1.8
Thank you for the work.
But the UUID description is still not solving the issue already mentioned in https://github.com/oasis-tcs/cti-stix2/issues/133.
The current proposal in the draft:
"All identifiers, excluding those used in the deprecated cyber observable container, MUST follow the form object-type--UUID, where object-type is the exact value (all type names are lowercase strings, by definition) from the type property of the object being identified or referenced and where the UUID is either an RFC 4122-compliant Version 4 UUID or Version 5 UUID. The UUID portion MUST be generated according to the algorithm(s) defined in RFC 4122, section 4.4 (Version 4 UUID) or section 4.3 (Version 5 UUID) [RFC4122]."
Could this be updated in the following way:
"All identifiers, excluding those used in the deprecated cyber observable container, MUST follow the form object-type--UUID, where object-type is the exact value (all type names are lowercase strings, by definition) from the type property of the object being identified or referenced and where the UUID is either an RFC 4122-compliant UUID. The UUID portion MUST be generated according to the algorithm(s) defined in RFC 4122, section 4 [RFC4122]."
We have an ongoing fork for the CTI STIX2 implementation and this change could solve a host of issues reported by several vendors / implementers that we are in contact with.
Could we count on the TC for ensuring this is passing in STIX 2.1? Because this is a major blocker and I would be very disappointed to keep having to maintain our fork of the STIX 2 libraries, especially considering the rather steep effort required to keep it in line.
Thank you very much.
-- Alexandre Dulaunoy CIRCL - Computer Incident Response Center Luxembourg 16, bd d'Avranches L-1160 Luxembourg info@circl.lu- www.circl.lu- (+352) 247 88444
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]