Add Sharing Groups

[boschpsirt]

At the document level there is a Publisher sub-item. There are some use cases where a publisher does not write an advisory for all customers, but rather publishes it for each one with appropriate additional information. In human-readable format, this is in the title and in the watermark.

Would it be possible to expand this for this or the next release? I could imagine placing Publisher and Document References directly between the points in the Secvisogram and adapting them accordingly to CSAF.

[tschmidtb51]

I could imagine to extend the distribution by an item called sharing_group. A required id would be a uuid and there could be an optional human-readable name. This should allow for such situations.

Note: CSAF documents that differ in content MUST use different /document/tracking/id. Given your suggestion that can easily be done by appending the /document/distribution/sharing_group/id to the /document/tracking/id.

[tschmidtb51]

@boschpsirt Please also formally notify about the suggestion by writing to the csaf-comment mailing list (as soon as its back online).

[boschpsirt]

I could imagine to extend the distribution by an item called sharing_group. A required id would be a uuid and there could be an optional human-readable name. This should allow for such situations.

Note: CSAF documents that differ in content MUST use different /document/tracking/id. Given your suggestion that can easily be done by appending the /document/distribution/sharing_group/id to the /document/tracking/id.

Hi Thomas,

we agree with this proposal.

[tschmidtb51]

Another use case for the suggested field is access restricted advisories. The addition of this field will allow automatic decision which CSAF documents show be displayed/accessible by which group based on the sharing_group/id. Therefore, it can also be used during the CVD process to provide data or an advisory stub automatically.

[santosomar]

Call to action sent by @tschmidtb51
Requests that all TC members review the suggested object sharing_groups within the next two weeks (2024-05-08) and comment in the issue directly.

https://groups.oasis-open.org/discussion/call-to-action-for-705

This should be discussed in the next meeting or a motion placed before the meeting on May 29th.

[tschmidtb51]

We will use UUIDv4.

Here is some background information regarding the choice of the uuid form (thanks to @bernhardreiter for looking into that and collecting information for the decision):

Overview

Version	suited	comment
1	no	superseded by 6
2	no	legacy
3	no	name based MD5
4	yes	random value
5	no	name hashed SHA1
6	no	time based (improved on with 7)
7	yes	time and random based
8	no	custom algorithms

Details

For sharing_group/ids a high resolution of time stamps is not necessary.

Thus, according to RFC 9562, only UUIDv4 and UUIDv7 are good candidates for the use as id in sharing_groups.

UUIDv6 is a replacement for UUIDv1 inheriting some drawbacks.

And UUIDv7 is an improvement over both. UUIDv7 uses the well-known Unix Epoch timestamp source, which takes up less space, so random values could be added. This means there is a lower risk of collisions and of being guessed.

UUIDv3 and UUIDv5 compute hash over a name. This is not needed and in addition both MD5 and SHA1 algorithms are not considered cryptographic secure for all uses in the next years, so just the mention of any of theses algorithms in a new standard will add the requirement to add a paragraph of justification and make implementations more difficult because existence of any code for these hashes is questioned in context of certified security.

UUIDv8 is application specific and would add the burden to specify the algorithms in more depth which is too much effort and error prone for the envisioned simple usage. UUIDv2 is an legacy use case and not even specified in the RFC itself.

[tschmidtb51]

We will use lowercase in 8-4-4-4-12 notation. The omni UUID 'FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF'.toLower() can be used in a TLP:CLEAR scenario :-)

[tschmidtb51]

The issue was announced on the mailing list: https://groups.oasis-open.org/discussion/github-issue-705