Clarify the involvements section (1)

[tschmidtb51]

During the review of #205 there were some comments regarding the definitions and explanations use in the involvements property:

---

@tolim stated in #205 (comment):

It is unclear to me how this value should be used. I would assume that disputed in the context of the party means, that the named party and its affiliation to the vulnerability is disputed (and not the vulnerability report in its entirety).
If there is no security implication, the vulnerability CVSS score would indicate this by a value of 0.
Is there any case, where the value disputed would be used? At least from a vendor perspective, this value will never be useful as disputed or non-responding parties will not be mentioned in the advisory.

---

@sthagen replied in #205 (comment):

Defining categories in deeply nested structures sometimes makes us miss the forrest for the trees - I will read CVRF v1.2 again to see how we did there. Thanks for bringing this scope / use question up @tolim

---

This issue is used to track the progress and provide a place for discussions.

[tschmidtb51]

@tolim: What about this use case:

A security researcher (let's call him Bob) applies for a CVE and gets it granted by a CERT (let's call that CERT-XY). The vendor (say FooBar) states he is not affected. This brings us to the situation where:

• Bob could issue an advisory and use (state, party)-tuples: { (disputed, vendor), (completed, coordinator)
• CERT-XY could issue an advisory and use (state, party)-tuples: { (disputed, vendor), (completed, coordinator)
• FooBar could issue an "informational" advisory and use state disputed for the party vendor.

I agree that the latter one is probably unlikely.

Having written that example I think I see the problem too. The definition always refer to the vendor instead of referring to the party.

[tolim]

After reviewing the pull request, I agree to keep disputed in the spec. It definitely is useful for CERTs providing status reports on different vendors within one document.

[tschmidtb51]

Merged into the oasis-tcs/csaf:master through #265.