[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
Exactly. What I absolutely cannot fathom is what the arguments against this change are in the first place - is it a breaking change that would prevent us from ingesting content generated with STIX 2.0? Nope, UUIDv4/v5 are subsets of the new supported values (anything in the RFC), so we're all good. Did anyone come forward with sane arguments why we should enforce this? The only attempt I saw was pointing at an example of an obvious slip-up with some UUIDs being copy-pastaed into several objects causing collisions in a report - obviously something that happened due to user-error and a strong demonstration of how the entire issue is being misunderstood / misrepresented. Bret, I honestly don't understand the resistance against this. Can you personally think of any valid reason why this would be counter-productive besides the argument that we've probably made a short-sighted decision as a TC and thus we should suffer from it for all eternity to remind us of our past mistakes? :) Best regards, Andras On 30.04.19 03:52, Jason Keirstead wrote: > Bret; respectfully I am not alone here. There are 3 other people in this > thread all of whom agree with me and we've said this multiple times over > the past weeks. > > I just don't understand what the value proposition is in these > restrictions. And no one is really coming to bat to support them. No > one came to bat to support them a few weeks ago either. > > What purpose do they serve? They don't help interoperability at all, and > that's the whole purpose of STIX. > > > - > Would you like me to give you a formula for success? It's quite simple, > really. Double your rate of failure. > > - Thomas J. Watson > > Bret Jordan --- Re: [cti] Re: [EXT] Re: [cti] Items Ready for TC Wide > Final Review --- > > From: "Bret Jordan" <Bret_Jordan@symantec.com> > To: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>, "Piazza, Rich" > <rpiazza@mitre.org> > Cc: "Alexandre Dulaunoy" <Alexandre.Dulaunoy@circl.lu>, > cti@lists.oasis-open.org, "Patrick Maroney" <pmaroney@darklight.ai>, > "Sean Barnum" <sean.barnum@FireEye.com> > Date: Mon, Apr 29, 2019 6:31 PM > 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 > <https://clicktime.symantec.com/35hQaU4GUwPCdEhYvTz4HzM7Vc?u=www.ibm.com%2Fsecurity> > > "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>* > Date: *Monday, April 29, 2019 at 1:44 PM* > To: *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>* > Subject: *[EXT] Re: [cti] Items Ready for TC Wide Final Review > >  > > I agree with this text. > > Then we can publish a separate work product for the recommended OASIS > CTI namespace UUID(s) and the accompanying name generation algorithm(s) > for said versions. > > Having it separate makes it easier to evolve and amend. > > - > Jason Keirstead > Lead Architect - IBM Security Connect_ > __www.ibm.com/security_ > <https://clicktime.symantec.com/35hQaU4GUwPCdEhYvTz4HzM7Vc?u=www.ibm.com%2Fsecurity> > > "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:    ÂSean Barnum <sean.barnum@FireEye.com> > To:    ÂPatrick Maroney <pmaroney@darklight.ai>, Alexandre Dulaunoy > <Alexandre.Dulaunoy@circl.lu>, "cti@lists.oasis-open.org" > <cti@lists.oasis-open.org> > Date:    Â04/29/2019 02:25 PM > Subject:    ÂRe: [cti] Items Ready for TC Wide Final Review > Sent by:    Â<cti@lists.oasis-open.org> > > ------------------------------------------------------------------------ > >  > > +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>* > Date: *Monday, April 29, 2019 at 10:58 AM* > To: *Alexandre Dulaunoy <Alexandre.Dulaunoy@circl.lu>, > "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>* > Subject: *Re: [cti] Items Ready for TC Wide Final Review > >  > > 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-type/is the exact value (all type names are lowercase strings, > by definition) from the typeproperty of the object being identified or > referenced and where the /UUID/is an RFC 4122-compliant UUID. The UUID > *MUST* be generated according to the algorithm(s) defined in RFC 4122, > [_RFC4122_ > <https://clicktime.symantec.com/3QEUuMu66P4joT3jiaH72zr7Vc?u=http%3A%2F%2Fdocs.oasis-open.org%2Fcti%2Fstix%2Fv2.0%2Fcs01%2Fpart1-stix-core%2Fstix-v2.0-cs01-part1-stix-core.html%232zqjjj5wdk2h>]. > >  > >  > > *Patrick Maroney* > > *DarkLight* > > Mobile: (609)841-5104 > > Email: Â_patrick.maroney@darklight.ai_ <mailto:patrick.maroney@darklight.ai> > >  > > _www.darklight.ai_ > <https://clicktime.symantec.com/3YTLjyLvYyuCf1pREGLUBR57Vc?u=http%3A%2F%2Fwww.darklight.ai> > >  > >  > > *From: *"cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf > of Alexandre Dulaunoy <Alexandre.Dulaunoy@circl.lu>* > Organization: *CIRCL - Computer Incident Response Center Luxembourg* > Date: *Monday, April 29, 2019 at 10:34 AM* > To: *"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>* > Subject: *Re: [cti] Items Ready for TC Wide Final Review > >  > > 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 > > _https://docs.google.com/document/d/1ShNq4c3e1CkfANmD9O--mdZ5H0O_GLnjN28a_yrEaco/edit#heading=h.klv9fmnhjhrc_ > <https://clicktime.symantec.com/33BiiHtHvkoB6DyLMz6ikQ97Vc?u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1ShNq4c3e1CkfANmD9O--mdZ5H0O_GLnjN28a_yrEaco%2Fedit%23heading%3Dh.klv9fmnhjhrc> > >  > > 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_ > <https://clicktime.symantec.com/3UTXhredRrzc4uQUiw26Too7Vc?u=https%3A%2F%2Fgithub.com%2Foasis-tcs%2Fcti-stix2%2Fissues%2F133>. > >  > > 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_ <mailto:info@circl.lu>- _www.circl.lu_ > <https://clicktime.symantec.com/3Xxu929xgnKSHkdP4d5uwqU7Vc?u=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_ > <https://clicktime.symantec.com/33F4pL2Gp6d5gNp4GMxG2fy7Vc?u=https%3A%2F%2Fwww.oasis-open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php> > >  > >  > > > This email and any attachments thereto may contain private, > confidential, and/or privileged material for the sole use of the > intended recipient. Any review, copying, or distribution of this email > (or any attachments thereto) by others is strictly prohibited. If you > are not the intended recipient, please contact the sender immediately > and permanently delete the original and any copies of this email and any > attachments thereto. > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]