Provider Metadata - Feedback needed

["Schmidt, Thomas" <thomas.schmidt@bsi.bund.de>]

Dear colleagues,

you were probably expecting the next (and hopefully final) editor revision right now. Unfortunately, it is not ready yet. We made significant progress but came across one problem:

As we all know automation is needed and this includes the discovery which organisations provide CSAF documents. Several options were defined for that:
- through security.txt
- through Well-known URL
- through DNS path

However, it might be tricky to have an idea under which domain to look for those - especially if you provide your services in more than one country and therefore have multiple domains under different TLDs (e.g. .com, .de, .co.au,...). To solve this problem, the CSAF lister was suggested (in #152, previously known as CSAF aggregator light). It is basically a role which provides a list of URLs of known CSAF distribution points. That means where issuing parties (CSAF publisher, CSAF provider, CSAF trusted provider) publish their CSAF documents.

To ease the adoption (especially for SME and starters) we specified 2 approaches how to distribute CSAF documents:
- a directory-based approach
- a ROLIE based approach

Unfortunately, this makes it harder for the user to determine which approach is used (since currently the issuing party doesn't have to tell that explicitly).

CSAF publisher (which is the basic role) don't even provide any level of automation. As the number of issuing parties can get big easily (with different level of automation), the CSAF aggregator was suggested (also in #152). It collects the CSAF documents from different issuing parties and provides them as a one-stop-shop in the best automatable way.

Given that the metadata is currently missing, it is a real hard problem to collect/add this data as a CSAF aggregator in an automated way. Moreover, it is unclear where the issuing party is okay with a mirror of its documents.

To solve these issues, I came up with a (simple) solution: The issuing party provides the metadata itself. We can than extract the necessary data automated. This does not apply for CSAF publisher which currently do not support any automation - so there is no need for that additional requirement. A CSAF aggregator has to list the manually anyway. (At that time they SHOULD try to convince them to become a CSAF provider ;-)).

Please see the full amount of changes for that solution sketched out in https://github.com/oasis-tcs/csaf/pull/290. Please provide feedback (either directly at the PR (preferred) or on the mailing list).

If you have any questions, do not hesitate to contact me.

Best regards,
Thomas

PS: As soon as we have a consens here, I'm happy to add the additional examples.