OASIS Cyber Threat Intelligence (CTI) TC

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

"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
type property 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 ].
 
 
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.

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> 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 "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 type property
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 ].     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.

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>
Date: Monday, April 29, 2019 at 2:18 PM
To: Rich Piazza <rpiazza@mitre.org>
Cc: Alexandre Dulaunoy <Alexandre.Dulaunoy@circl.lu>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Patrick Maroney <pmaroney@darklight.ai>, Sean Barnum <sean.barnum@FireEye.com>
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" <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

"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
type property 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 ].
 
 
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.

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" <rpiazza@mitre.org> To:         Jason Keirstead <Jason.Keirstead@ca.ibm.com> Cc:         Alexandre Dulaunoy <Alexandre.Dulaunoy@circl.lu>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Patrick Maroney <pmaroney@darklight.ai>, Sean Barnum <sean.barnum@FireEye.com> Date:         04/29/2019 03:25 PM Subject:         [cti] Re: [EXT] Re: [cti] Items Ready for TC Wide Final Review Sent by:         <cti@lists.oasis-open.org> 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> Date: Monday, April 29, 2019 at 2:18 PM To: Rich Piazza <rpiazza@mitre.org> Cc: Alexandre Dulaunoy <Alexandre.Dulaunoy@circl.lu>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Patrick Maroney <pmaroney@darklight.ai>, Sean Barnum <sean.barnum@FireEye.com> 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" <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 "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 type property 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 ].     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.

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> 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 "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 type property 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 ].     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.

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 "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 "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 type property 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 ].     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.

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

I am with Jason, Andras and Pat on this. I do not view this as a drastic or significant change. This portion of the spec is currently undergoing change exactly because the original language was shown to be overly restrictive in its limitation to UUIDv4. One possible solution is to only add in UUIDv5 which is where we currently stand but that just moved us a little closer to where we should be but still leaves us with clearly overly restrictive limitations as has been pointed out. I also do not agree with a characterization that this is one or two people wishing to overturn the will of the rest of the TC. There have been quite a few people voicing concern with the overly restrictive language (especially recently but some of us for a long time) and as Jason and Andras point out I have not really heard anyone arguing strongly to keep the overly restrictive language especially not with any explicit rationale or justifying evidence why it should be there. I agree with you that we need to be careful not to reargue the same debates over and over as we will not make progress. At the same time, when issues are identified and people understand the need to change something we similarly cannot reject it simply because it represents change. If we do that we may make progress but it will not be forward toward our mutual goal but rather backward or sideways away from it. Sean Barnum Principal Architect FireEye M: 703.473.8262 E: sean.barnum@fireeye.com ïOn 4/30/19, 9:31 AM, "cti@lists.oasis-open.org on behalf of Andras Iklody" <cti@lists.oasis-open.org on behalf of andras.iklody@circl.lu> wrote: 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. > > > > --------------------------------------------------------------------- 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.