Ballot Details: Identifier Proposal (CLOSED)

Ballot Question Should we use UUIDv4 as our default format for identifiers?
Ballot Description NOTE: The purpose of this ballot is to unify the TC and settle an issue that has been debated since the face-to-face (F2F) in January. This is a non-binding ballot that can be reversed at any time in the future by simple majority vote of the TC.

Elaboration:
============
At the January Face-to-Face (F2F) there was general consensus that all objects should have IDs and that the default form should be UUIDs. However, recently discussion has turned to using other formats or mechanisms to generate IDs. Please refer to the "Deterministic IDs - pas de deux" thread on the cti-stix mailing list for more detail on the debate.

To attempt to gain TC-wide consensus in the short term, Bret Jordan motioned for and John Wunder seconded the motion for this ballot to settle the issue of whether or not UUIDs should be used as identifiers instead of some alternative format or mechanism.

The STIX subcommittee has created some draft language, which can be found here in Section 4.5:

https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.ko24ggw4eq0q

For those who do not have access to the Google Doc, you can request it from Bret Jordan. However, here is the detail from the section:

"An identifier uniquely identifies a STIX top-level object. Identifiers MUST follow the form [object-type]--[UUIDv4], where [object-type] is the exact value from the type field of the object being identified or referenced and [UUIDv4] is an RFC 4122 compliant Version 4 UUID. The uuid field MUST be generated according to the algorithm(s) defined in RFC 4122, Section 4.4 (Version 4 UUID)."

For example, an ID in STIX 2.0 JSON would look like this:

{
"type": "indicator",
"id" "indicator--e2e1a340-4415-4ba8-9671-f7343fbf0836",
...
}
Ballot Options
VOTING CLOSED: Tuesday, 17 May 2016 @ 2:00 pm EDT
Yes 33 86.842
No 5 13.158
Abstain 1
Open Date Tuesday, 10 May 2016 @ 2:00 pm EDT
Close Date Tuesday, 17 May 2016 @ 2:00 pm EDT
Ballot Type Official, as defined by organization policies and procedures

Voting Statistics

Number of votes cast (excluding abstentions) 38
Eligible members who have voted 39 of 54 72.222%
Eligible members who have not voted 15 of 54 27.778%

Voting Summary by Option

Options with highest number of votes are bold
Option # Votes % of Total
Yes 33 86.842%
No 5 13.158%
Abstain 1

Voting Details

Voter Name Company Vote * Time (UTC) Comments
* Baker, Jonathan Mitre Corporation Yes 2016-05-11 18:17:00
* Brown, Iain United Kingdom Cabinet Office Yes 2016-05-10 18:40:00
* Butt, Michael Soltra Yes 2016-05-11 13:56:00
* Chernin, Aharon Soltra Yes 2016-05-10 20:39:00
* Clancy, Mark Soltra Yes 2016-05-11 13:36:00
* Coderre, Robert VeriSign Yes 2016-05-17 11:09:00
* Darley, Trey Soltra Yes 2016-05-11 10:01:00
* Davidson, Mark Soltra Yes 2016-05-10 18:10:00
* Eilken, David Financial Services Information Sharing and... Yes 2016-05-11 15:42:00
* Ginn, Jane Cyber Threat Intelligence Network, Inc. (C... Yes 2016-05-11 02:32:00
* Gurney, John-Mark New Context Services, Inc. Yes 2016-05-12 15:20:00
* Jones, Elysa Individual Yes 2016-05-11 18:17:00
* Jordan, Bret Blue Coat Systems, Inc. Yes 2016-05-10 20:00:00
* Katz, Gary US Department of Defense (DoD) Yes 2016-05-11 17:21:00
* Keckler, Raymond Soltra Yes 2016-05-13 12:50:00
* Kelley, Sarah Center for Internet Security (CIS) Yes 2016-05-10 18:51:00
* Khan, Ali Soltra Yes 2016-05-13 13:32:00
* Kiehl, Chris Soltra Yes 2016-05-11 17:02:00
* Kirillov, Ivan Mitre Corporation Yes 2016-05-10 18:09:00
* MacDonald, Terry Individual Yes 2016-05-11 01:31:00
* Masuoka, Ryusuke Fujitsu Limited Yes 2016-05-11 10:40:00
* Maxwell, Kyle VeriSign Yes 2016-05-11 17:30:00 1
* Moler, James New Context Services, Inc. Yes 2016-05-13 18:46:00
* Peloquin, Joey Citrix Systems Yes 2016-05-16 17:54:00
* Pepin, Michael Soltra Yes 2016-05-10 19:16:00 1
* Piazza, Richard Mitre Corporation Yes 2016-05-10 18:27:00
* Riedel, Daniel New Context Services, Inc. Yes 2016-05-12 18:31:00
* Struse, Richard DHS Office of Cybersecurity and Communicat... Yes 2016-05-12 15:22:00
* Suarez, Natalie Soltra Yes 2016-05-13 13:02:00
* Taylor, Chris United Kingdom Cabinet Office Yes 2016-05-10 20:07:00
* Thompson, Dean Australia and New Zealand Banking Group (A... Yes 2016-05-17 13:48:00
* Thomson, Allan LookingGlass Yes 2016-05-11 14:15:00
* Wunder, John Mitre Corporation Yes 2016-05-10 18:17:00
* Barnum, Sean Mitre Corporation No 2016-05-16 13:20:00 1
* Foley, Alexander Bank of America No 2016-05-16 18:06:00
* Maroney, Patrick Integrated Networking Technologies, Inc. No 2016-05-10 18:12:00 1
* Mates, Jeffrey US Department of Defense (DoD) No 2016-05-12 16:50:00 1
* Patrick, Paul FireEye, Inc. No 2016-05-13 20:01:00 1
* Taylor, Marlon DHS Office of Cybersecurity and Communicat... Abstain 2016-05-13 18:58:00 1
* Baikalov, Igor Securonix --
* Beekman, Jeff Soltra --
* Butts, Brad U.S. Bank --
* Davidson, Ron Check Point Software Technologies --
* DePeppe, Doug Cyber Threat Intelligence Network, Inc. (C... --
* Dye, Daniel Soltra --
* Kakumaru, Takahiro NEC Corporation --
* Keirstead, Jason IBM --
* Pumo, Beth Kaiser Permanente --
* Schmoker, Ben ThreatConnect, Inc. --
* Storms, Andrew New Context Services, Inc. --
* Terada, Masato Hitachi, Ltd. --
* Thomson, Laurie United Kingdom Cabinet Office --
* Verma, Jyoti Cisco Systems --
* Williams, Ron IBM --

Voter Comments

Submitter Vote Comment
Maxwell, Kyle
VeriSign
Yes Specifically, deterministic UUIDs are not necessary. Pseudo-random UUIDs meet all our requirements and do not cause additional confusion or problems for implementers, nor block future development based on choices made regarding immutable properties.
Pepin, Michael
Soltra
Yes is the "--" a typo in the example?
"indicator--e2e1a340-44­15-4ba8-9671-f7343fbf083­6"

Shouldn't it be?
"indicator-e2e1a340-441­5-4ba8-9671-f7343fbf0836­"
Mates, Jeffrey
US Department of Defense (DoD)
No I don't like the idea of removing the possibility of supporting deterministic UUIDs for vendors or producers who choose to create these.
Maroney, Patrick
Integrated Networking Technologies, Inc.
No The current language arbitrarily constrains the RFC 1422 UUID identifier to the UUIDv4 pseudo-random generation method.

The *** only *** functional requirement for the UUID is that it is "unique". The use cases for alternative methods have been provided and this decision prevents use of alternative methods by making uuidv4 a "Must" requirement.

Note the Ballot states "as our default format" whereas the language above states uuidv4 is a "Must Requirement", which is it?
Barnum, Sean
Mitre Corporation
No I have seen no logical rationale provided for precluding the use of RFC 1422 compliant UUIDs other than UUIDv4.

I have seen several comments asserting that somehow "allowing" users/implementers to use RFC 1422 compliant UUIDs that are deterministically generated somehow "requires" the TC to define and agree on THE method (algorithm and parameter properties) that must be used for deterministic generation and that UUIDv4 would not be possible. This is a mischaracterization of the issue in question as has been explained by multiple people on the list.

It is completely possible to "allow" the use of RFC 1422 compliant UUIDs other than UUIDv4 without "requiring" anything from users/implementers other than what they would need to do if you required UUIDv4.

All you need to do is require that the UUIDs are RFC 1422 compliant and that they should be presumed to be opaque (you don't know how they were generated). Individual organizations or trust communities can choose to override the presumption of opaqueness for themselves but any party outside of that organization or trust community can just treat them as any randomly generated UUID.

It is as simple as that.

The fact that one party in the TC does not plan to utilize some capability should not preclude others from doing so if inclusion of that capability places no barrier or burden on the party not wishing to utilize it.
Patrick, Paul
FireEye, Inc.
No I voted 'No' because the intent of this vote is to preclude the use of deterministic Identifiers and the use of other formats defined in RFC 4122. Unfortunately, the ballot question as formed is also misleading when one reads the elaboration text or draft document where it explicitly precludes the use of uuid formats other than UUIDv4. To most people the term 'Default' indicates that there is more than one option, which is not true in this case.
Taylor, Marlon
DHS Office of Cybersecurity and Communicat...
Abstain From my understanding, I might be incorrect, the passing of this non-binding ballot places the TC in a situation where it is possible to have multiple STIX top-level objects with the exact same data having different identifiers.
Examples:
{
"type":"indicator",
"id":"indicator--e2e1a3­40-4415-4ba8-9671-f7343f­bf0863",
"pattern":"file-object:­name MATCHES /^.+\.exe$/"
}

{
"type":"indicator",
"id":"indicator--e2e1a3­40-4415-4ba8-9671-f7343f­bf0386",
"pattern":"file-object:­name MATCHES /^.+\.exe$/"
}

{
"type":"indicator",
"id":"indicator--e2e1a3­40-4415-4ba8-9671-f7343f­bf0638",
"pattern":"file-object:­name MATCHES /^.+\.exe$/"
}

Is this something that the TC wants?