Serve ROLIE service and category documents

[bernhardreiter]

Implement serving of

• [x] 7.1.16 Requirement 16: ROLIE service document
• [x] 7.1.17 Requirement 17: ROLIE category document

Both should have the options to either not write the document or configure the contents in the configuation file.

For the category document a third variant should take and update the contents from the advisories.

(also a topic for the aggregator? At least to check if it is served.)

https://docs.oasis-open.org/csaf/csaf/v2.0/csd01/csaf-v2.0-csd01.html#7116-requirement-16-rolie-service-document https://docs.oasis-open.org/csaf/csaf/v2.0/csd01/csaf-v2.0-csd01.html#7117-requirement-17-rolie-category-document

[s-l-teichmann]

@tschmidtb51 : A few questions:

For the service document:

• The document should be placed under .well-known/csaf/service.json ?
• If I understand it correctly the document only lists the ROLIE feeds in the collection list in its workspace. This list could be generated from the tlps list in the configuration of the provider like it is already done the case for the ROLIE feed references in the provider-metadata.json. All what is needed is an extra flag in the configuration if we should do it at creation time, right?
• Is there more what needs to configured in the service document?

For the category document:

• There should be a document per feed? Right next to the feed-tlp-$TLP.json documents?
• Or should there only be one right next to the service.json document?
• For the configuration we can use a list of terms as strings?
• If this list is not existent we do not generate the category documents at all.
• If the list is not empty we create hard-code the terms at creation time.
• If the list is empty we use the incoming advisories to extract the terms from, right?
• In the last case which element in the advisories should be used?

[tschmidtb51]

@s-l-teichmann Sorry about the delay:

For the service document:

• The document should be placed under .well-known/csaf/service.json ?

That is not a hard requirement. It could also be placed at /.well-known/service.json or /.well-known/rolie/service.json. The RFC even uses /rolie/servicedocument in its examples. However, for simplicity, I would go with the path you suggested.

• If I understand it correctly the document only lists the ROLIE feeds in the collection list in its workspace. This list could be generated from the tlps list in the configuration of the provider like it is already done the case for the ROLIE feed references in the provider-metadata.json. All what is needed is an extra flag in the configuration if we should do it at creation time, right?

Basically, yes. However, each feed should be in a separate collection as the have different access level.

• Is there more what needs to configured in the service document?

The service document lists for each feed the categories given for that feed. The feed MUST list the service document, if it exists: "A ROLIE Feed MUST [if a ROLIE Service Document exists] contain one or more "atom:link" elements with rel="service" and an "href" attribute whose value is a URI that points to an Atom Service Document associated with the Feed."

For the category document:

* There should be a document per feed? Right next to the `feed-tlp-$TLP.json` documents?

Yes. This avoids information leaks.

• Or should there only be one right next to the service.json document?

Could be an option but I guess that would be an enhancement.

• For the configuration we can use a list of terms as strings?

Yes.

• If this list is not existent we do not generate the category documents at all.

Yes.

• If the list is not empty we create hard-code the terms at creation time.

Yes. In that case, the user should be able to assign category values to the advisories at upload time.

• If the list is empty we use the incoming advisories to extract the terms from, right?

Yes.

• In the last case which element in the advisories should be used?

It would be great, if we could configure that. The standard lists the following that can be extracted:

• document category
• document language
• values of the branch category within the Product Tree including but not limited to

  vendor
  product_family
  product_name
  product_version

  If that is to complex, use all except the product_version.

[s-l-teichmann]

Concerning the categories PR #208 implements the following approach: If the categories is empty or not configured at all no category document is created. If an item in the list starts with expr: the rest of the string is interpreted as a JSONPath expression an is used to extract a corresponding string from the incoming advisories. If the string is not prefixed the string is taken verbatim as a category. I think that should be flexible enough.

[tschmidtb51]

Sounds great!

[bernhardreiter]

Solved by #208.