[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [EXT] Re: [cti] Items Ready for TC Wide Final Review
|
The text I suggested just makes everyone happy (or less unhappy). Even the issue that Alexandre referred to says:
âWe ask to change the specification to relax the UUID format and mention that Version 4 of the UUID is only RECOMMENDED.â Then maybe we can move on? From: Jason Keirstead <Jason.Keirstead@ca.ibm.com> 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.
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]