ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Comment Resolution Account for STIX 2.0 CSDPR01
2
Prepared:20 April 2017
3
4
Comment #Public reviewDate providedLink to emailCommenterCategoryComment provided / Issue raisedTC decision on resolution Comments / Changes
5
1stix2.0-csdpr0123-03-2017
https://lists.oasis-open.org/archives/cti-comment/201703/msg00001.html
John-Mark Gurney
SubstantiveAdd an optional "hash" property to the external-reference type to capture the hash of the referenced content.ACCEPT
Moved hashes-type to part 1. Renamed to hashes. Moved hash-algo-ov to part 1, renamed to hash-algorithm-ov.

Added field called "hashes" to external-reference type, of type hashes.
6
2stix2.0-csdpr0123-03-2017
https://lists.oasis-open.org/archives/cti-comment/201703/msg00002.html
John-Mark Gurney
ExamplesChange examples that currently use md5 to use some other hash (given md5 is known to be insecure)ACCEPT
Left 3 examples of MD5 (1 in part 3, 2 in part 5). Examples were updated to SHA-256 and ssdeep
7
3stix2.0-csdpr0123-03-2017
https://lists.oasis-open.org/archives/cti-comment/201703/msg00003.html
Bret JordanEditorialUpdate the participants listTODO
Participants list was updated across Part 1-5
8
4stix2.0-csdpr0127-03-2017
https://lists.oasis-open.org/archives/cti-comment/201703/msg00004.html
John WunderEditorialPart 1: Update section 5.1.2 to correct the data markings description to indicate that they can't have relationships.ACCEPT
Updated section 4.1.2 (incorrect number in comment) to indicate that data-marking is not a STIX object and can't have relationships. Removed listing of relationships from the table.
9
5stix2.0-csdpr0127-03-2017
https://lists.oasis-open.org/archives/cti-comment/201703/msg00004.html
John WunderExamplesPart 2: Attack pattern example: external_reference should have an external_id property
ACCEPTFixed
10
6stix2.0-csdpr0127-03-2017
https://lists.oasis-open.org/archives/cti-comment/201703/msg00004.html
John WunderExamplesPart 2: The create time of the malware in the coa example is after the create time of the relationship that refers to it
ACCEPT
changed relationship created property
11
7stix2.0-csdpr0127-03-2017
https://lists.oasis-open.org/archives/cti-comment/201703/msg00004.html
John WunderExamplesPart 2: The COA Example has a typo. The Malware SDO at the bottom of the example has a property called `relationship_type` which should actually be `name`
ACCEPT
changed relationship_type to name
12
8stix2.0-csdpr0127-03-2017
https://lists.oasis-open.org/archives/cti-comment/201703/msg00004.html
John WunderExamplesPart 2: 2016-01-201T17:00:00Z in the report example has a 3 digit day
ACCEPT
added milliseconds, and fixed date
13
9stix2.0-csdpr0127-03-2017
https://lists.oasis-open.org/archives/cti-comment/201703/msg00004.html
John WunderExamplesPart 2: The threat-actor example is pretty skimpy and should be expanded
ACCEPTadded several properties
14
10stix2.0-csdpr0127-03-2017
https://lists.oasis-open.org/archives/cti-comment/201703/msg00004.html
John WunderSubstantivePart 4: home_dir in unix-account-ext isn't a ref to a directory object, but just a string
REJECT (TODO: Confirm with community)
Matches how this is generally captured by Unix systems
15
11stix2.0-csdpr0127-03-2017
https://lists.oasis-open.org/archives/cti-comment/201703/msg00004.html
John WunderSubstantivePart 4: the x509 extension is named inconsistently: most other extensions are "foo_ext", this one is 'x509-v3-extensions-type'
REJECT w/ Clarification
Added a clarification that it describes x509 extensions, not a STIX Extension for x.509.
16
12stix2.0-csdpr0127-03-2017
https://lists.oasis-open.org/archives/cti-comment/201703/msg00004.html
John WunderEditorialPart 4: In the x509-certificate properties table, there is no entry for extension, even though it has one.
REJECT
Given resolution of #11, no change necessary
17
13stix2.0-csdpr0127-03-2017
https://lists.oasis-open.org/archives/cti-comment/201703/msg00004.html
John WunderExamplesPart 4: Timestamp in pe-binary-file needs a trailing Z
ACCEPTadded Z
18
14stix2.0-csdpr0127-03-2017
https://lists.oasis-open.org/archives/cti-comment/201703/msg00004.html
John WunderExamplesPart 4: Windows-service-ext example should have service_name, not display_name
ACCEPTAdded service name
19
15stix2.0-csdpr0127-03-2017
https://lists.oasis-open.org/archives/cti-comment/201703/msg00004.html
John WunderExamplesPart 4: In the x509 example, validity_not_before and validity_not_after are after subject – but that is not the order in the table. No big deal – but examples usually follow the order in the table.
ACCEPTre-order
20
16stix2.0-csdpr0128-03-2017
https://lists.oasis-open.org/archives/cti-comment/201703/msg00005.html
Chris LenkExamplesPart 2: In the Indicator example: pattern should say 'file:hashes.MD5' (not 'file.hashes...')ACCEPTreplaced period with colon
21
17stix2.0-csdpr0128-03-2017
https://lists.oasis-open.org/archives/cti-comment/201703/msg00005.html
Chris LenkExamplesPart 2: In the Report example with bundle: indicator pattern should say 'file:hashes.MD5' (not 'file.hashes...')ACCEPTreplaced period with colon
22
18stix2.0-csdpr0128-03-2017
https://lists.oasis-open.org/archives/cti-comment/201703/msg00005.html
Chris LenkExamplesPart 4: In the “Basic Stream Socket” socket-ext example: is_listening should be a boolean, not a string.ACCEPTchanged to boolean
23
19stix2.0-csdpr0128-03-2017
https://lists.oasis-open.org/archives/cti-comment/201703/msg00006.html
John-Mark Gurney
SubstantiveI propose removing the description property from Part 3, section 3.1 Common Properties, as it does not add to the "facts" of what a cyber observable object is. I am not sure why this is present. As most Cyber Observables will be machine generated, or will be encapsulated in another context which can provide the needed context, this seems not useful.ACCEPT
removed property from section 3.1 in part 3 and from summary row of tables in part 4.
24
20stix2.0-csdpr0128-03-2017
https://lists.oasis-open.org/archives/cti-comment/201703/msg00007.html
Terrance Mckay
SubstantiveUpon review of the STIX 2.0 standard I have found what appears to be a missing relationship between the Indicator and Vulnerability objects. It would seem prudent that an "Indicator" object would be able to "indicate" a "Vulnerability". However the draft standard does not list this as a defined type of relationship. I believe this is an important relationship for the standard, as being able to publish proactive indicators that indicate a vulnerability would be very beneficial to detect and remediate a vulnerability before it is exploited by an adversary.REJECTDefer to 2.1
25
21stix2.0-csdpr0128-03-2017
https://lists.oasis-open.org/archives/cti-comment/201703/msg00008.html
Edilson ArenasSubstantiveThis (comment 20) appears to be a reasonable suggestion, however, a close analysis of the definition of the SDOs shows that the Indicator, as the fundamental element of intelligence, focuses more on providing information to objectively describe or indicate a specific “Intrusion Set”, not a Vulnerability.
N/AN/A
26
22stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00000.html
Greg BackExamplesI noticed that many of the common required fields (including id, created, modified) are omitted from the examples in section 2.4.3 of part 2 (https://docs.oasis-open.org/cti/stix/v2.0/csprd01/part2-stix-objects/stix-v2.0-csprd01-part2-stix-objects.html#_Toc476230936) and replaced with ellipses. This is inconsistent with the examples for the other SDOs.ACCEPTAdded required fields
27
23stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialParts 1-5 fail to distinguishe between normative and non-normative text, don't use notes for non-normative materials. https://issues.oasis-open.org/browse/TAB-1520ACCEPT
Added text to intro saying that everything was normative except for overview, examples, etc.
28
24stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialParts 6 and 7 play no role in conformance clauses at all. Are they entirely optional? Non-Normative? https://issues.oasis-open.org/browse/TAB-1519ACCEPT
Added optional features for Section 7. Added note to Section 6 saying it's referenced from part 2.
29
25stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 - conformance clauses are vague. Saying "all requirements" is a good way to lead to onflicting implementations. Say what they are in detail. https://issues.oasis-open.org/browse/TAB-1518ACCEPT
We rephrased this to identify that the relevant requirements are from the property table for that type.
30
26stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorial4.1 marking definitions - Speculation on the future is best a note, if not omitted alltogether (with respect to FIRST IEP) https://issues.oasis-open.org/browse/TAB-1517REJECT
No change, we felt this was important enough to include.
31
27stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorial4 data markings - We reference trust groups that have rules about which markings oferride other markings. If we talk about them, why not give references to them? Why leave the reader hanging? https://issues.oasis-open.org/browse/TAB-1516REJECT
No change, we don't want to reference the specific groups publicly.
32
28stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1, 3.3-3.4.2 is deeply confusing. Lots of text examples. https://issues.oasis-open.org/browse/TAB-1515REJECT w/ CAVEATS
We rejected most of the rewrite (the TC spent a lot of time on that section and feels it's good) but did incorporate parts of it. The rewrite also seemed to join together IDs, references, and versioning as concepts which isn't really accurate. Specific changes included adding some introductory text and changing a MAY to a non-normative can.
33
29stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 section 3.1 common properties, labels - Where is the suggested vocabulary? Cross-refs please. https://issues.oasis-open.org/browse/TAB-1514ACCEPT
Re-worded this section to make it clearer that the vocabulary was referenced from the usage of the STIX object
34
30stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 section 3.1 - What does it does it mean for an anonymous object to be 'revoked' and who does it? Without a created_by_ref, is it meaninful? https://issues.oasis-open.org/browse/TAB-1513ACCEPT
Added text to clarify that the object creator is still the object creator even if they don't fill in the created_by_ref field.
35
31stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 section 3.1 common properties, modified - Avoid incomplete statements. https://issues.oasis-open.org/browse/TAB-1512ACCEPTchange "update" to "set"
36
32stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 section 3.1 common properties created_by_ref - The interaction between an object without a created_by_ref property and versioning as well as revocation seems under defined. https://issues.oasis-open.org/browse/TAB-1511ACCEPT
Added text to clarify that the object creator is still the object creator even if they don't fill in the created_by_ref field.
37
33stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 section 3.1 common properties id - Don't presume perfect operation and define error condition for cases where objects of different types do in fact share the same ID. https://issues.oasis-open.org/browse/TAB-1510ACCEPT
changed "not possible" to "invalid"
38
34stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 section 3.1 common properties type - circular definition https://issues.oasis-open.org/browse/TAB-1509ACCEPT
Corrected to indicate that it's the name of a type, not the type itself.
39
35stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 all examples - Amend the Examples heading with what it purports to be an example of. https://issues.oasis-open.org/browse/TAB-1508REJECTWe didn't feel this made sense.
40
36stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 section 2.10 conflicts with 3.4.2 versioning timestamps https://issues.oasis-open.org/browse/TAB-1507ACCEPT
Added text to clarify that this simply meant the specific time the tool considers "creation"
41
37stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 section 2.8 Cross references to the suggested vocabularies and meaningful titles for those cross-references. BTW, names are defined elsewhere and should remain elsewhere. https://issues.oasis-open.org/browse/TAB-1506ACCEPT
42
38stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 section 2.7 list definition is confusing. It implies the list type defines a sort order, and if that isn't true, it needs to be dropped. Does it allow for empty lists? https://issues.oasis-open.org/browse/TAB-1505REJECT
Couldn't come up with any changes that didn't just make it more confusing.
43
39stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 section 2.5 integer representation - state the allowable number range rather than implying it. https://issues.oasis-open.org/browse/TAB-1504ACCEPT
44
40stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 section 2.4 identifier - distributed definitions for identifier are confusing. Suggest recasting identifier such that all parts of the identifier are fully defined here and ONLY here. https://issues.oasis-open.org/browse/TAB-1503ACCEPT w/ CAVEATS
Tried to clarify this with an additional example and better formatting.
45
41stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 section 2.3 floats - move RC7159 to normative references https://issues.oasis-open.org/browse/TAB-1502ACCEPT
46
42stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 section 2.3 float - since you can only represent a subpart of IEEE 754, why not simply start with the floating point definition of JSON? Don't worry about subsetting IEEE 754. https://issues.oasis-open.org/browse/TAB-1501REJECT
Couldn't identify a change that wouldn't just be more confusing.
47
43stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 - there are six examples under section 2.2.3, which isn't overly difficult. Use a consistent number of examples unless the material is clearly more compliated than most https://issues.oasis-open.org/browse/TAB-1500REJECT
48
44stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 section 2.2.1, properties order of listing - the prose and the table are in opposite ordering for "description, url, and external_id", Use the table order and revise the prose. https://issues.oasis-open.org/browse/TAB-1499ACCEPT
49
45stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 section 2.1 boolean - The normative MUST statement is unnecessary and confusing https://issues.oasis-open.org/browse/TAB-1498REJECT
Felt it is already clear, better to be precise
50
46stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialAll parts - font colors and styles - Reconsider the use of color for interpretation and the impact of accessibility requirements on governments and corporations. https://issues.oasis-open.org/browse/TAB-1497ACCEPT
Accept, will change one of the colors to blue
51
47stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 - section 1.5.1 naming conventions - Includes some text that isn't actually naming conventions, but rather requirements for matching and interpretation of property tables. Split and move the second paragraph. https://issues.oasis-open.org/browse/TAB-1496ACCEPT
Accept, moved to a new "Naming Requirements" section
52
48stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 section 1.4.6 Vocabularies - text is too vague, please include references for defined vocabularies. https://issues.oasis-open.org/browse/TAB-1495ACCEPT
Added new text with references and an example
53
49stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 section 1.4.3 STIX relationships - STIX relationship objects are defined, and then extended. Shorten and revise. https://issues.oasis-open.org/browse/TAB-1494ACCEPT
Added text to reference where embedded relationships are defined.
54
50stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 use of graph/node/edge - The only mention of it is in part 1.4.1 If the graph model isn't important enough to mention elsewhere, suggest tossing it as unnecessary https://issues.oasis-open.org/browse/TAB-1493REJECT
We felt this was important to explain how the STIX data model works.
55
51stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 abbreviation list is incomplete. If STIX content and STIX object qualify for inclusion in the abbreviation list, then why is STIX relationship excluded. Add STIX relationships to abbreviations. https://issues.oasis-open.org/browse/TAB-1492ACCEPT
Added definition for STIX Relationship and Embedded Relationship. Modified definition for SDO and SRO to indicate node/edge in a graph
56
52stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 section 1.1 terminology has a list of abbreviations that follows RFC2119. Suggest listing abreviations in a separate section. https://issues.oasis-open.org/browse/TAB-1491ACCEPT
Moved glossary to an appendix across all 5 parts
57
53stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 - there is no basis given for distinguishing between normative and non-normative text. https://issues.oasis-open.org/browse/TAB-1490ACCEPT
moved normative statements on serialization to conformance (in part 1). Added text to terminology section in all 5 parts to indicate which parts of the document are normative/non-normative (i.e. overview, examples, and text marked non-normative is not normative).
58
54stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 RFC references - RFC2119 has no DOI. https://issues.oasis-open.org/browse/TAB-1489ACCEPT
59
55stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 - I would drop RFC0020 as gratuitous and not necessary. https://issues.oasis-open.org/browse/TAB-1488ACCEPT
60
56stix2.0-csdpr0106-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00001.html
Patrick DurusauEditorialPart 1 - Is there some reason to use a dated reference to Unicode? It would exclude the use of any later editions. https://issues.oasis-open.org/browse/TAB-1487REJECT
Intentionally want to use some specific dated version, otherwise it could change from under us.
61
Post-Comment Period (TC Member Comments)
62
N/Astix2.0-csdpr0112-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00004.html
John-Mark Gurney
ExamplesOne of the patterning examples is incorrectACCEPT
63
N/Astix2.0-csdpr0117-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00005.html
Bret JordanExamples
In the versioning section, we use the term "title". However, after this section was written, we changed all of the SDOs to use "name". So we should fix these examples.
ACCEPT
64
N/Astix2.0-csdpr0118-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00006.html
John-Mark Gurney
EditorialUpdate hashes text to include restrictions on keysACCEPT
65
N/Astix2.0-csdpr0118-04-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00006.html
John-Mark Gurney
Substantive
Change patterning to use single quotes as an escape for keys rather than double quotes
ACCEPT
66
N/Astix2.0-csdpr0104-19-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00007.html
John-Mark Gurney
EditorialUse correct names of Unicode code pointsACCEPT
67
N/Astix2.0-csdpr0104-20-2017
https://lists.oasis-open.org/archives/cti-comment/201704/msg00008.html
Jason Keirstead
EditorialAdd references to relevant RFCs for URL and Domain NameACCEPT
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100