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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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


Subject: 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

"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-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

 

www.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

 

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

 

 


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]