I personally don't
really agree with that.
I don't think
we should be "recommending" version 4 or version version 5.
Which you should
use, is highly dependent on what you're trying to achieve. And any consumer
software should support both / all.
-
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" <>
To:
Jason
Keirstead <>
Cc:
Alexandre
Dulaunoy <>, ""
<>, Patrick Maroney <>,
Sean Barnum <>
Date:
04/29/2019
03:25 PM
Subject:
[cti]
Re: [EXT] Re: [cti] Items Ready for TC Wide Final Review
Sent
by: <>
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 <>
Date: Monday, April 29, 2019 at 2:18 PM
To: Rich Piazza <>
Cc: Alexandre Dulaunoy <>, ""
<>, Patrick Maroney <>,
Sean Barnum <>
Subject: 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" <>
To: Jason
Keirstead <>, Sean Barnum <>
Cc: Alexandre
Dulaunoy <>, ""
<>, Patrick Maroney <>
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:
<> on behalf of Jason Keirstead <>
Date: Monday, April 29, 2019 at 1:44 PM
To: Sean Barnum <>
Cc: Alexandre Dulaunoy <>, ""
<>, Patrick Maroney <>
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
"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 <>
To: Patrick
Maroney <>, Alexandre Dulaunoy <>,
"" <>
Date: 04/29/2019
02:25 PM
Subject: Re:
[cti] Items Ready for TC Wide Final Review
Sent by: <>
+1
Sean
Barnum
Principal
Architect
FireEye
M:
703.473.8262
E:
From:
<> on behalf of Patrick Maroney <>
Date: Monday, April 29, 2019 at 10:58 AM
To: Alexandre Dulaunoy <>, ""
<>
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:
www.darklight.ai
From:
"" <>
on behalf of Alexandre Dulaunoy <>
Organization: CIRCL - Computer Incident Response Center Luxembourg
Date: Monday, April 29, 2019 at 10:34 AM
To: "" <>
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
-
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.
