Re: [External] : [csaf] Provider Metadata - Feedback needed

[Feng Cao <feng.cao@oracle.com>]

I agree that the discovery about which organisations providing CSAF
documents is a valid issue and should be addressed when there are many
organizations using CSAF.

But is it really needed to be in CSAF 2.0? If there will be many
organizations providing CSAF in the next several months, please let me know.

A quick alternative solution might be to provide a host page (probably
in oasis or github) listing the organizations and their directories for
CSAF documents (the page format can be discussed), and this page can be
mentioned in CSAF 2.0 document so that each organization will have its
CSAF info added into the page. This TC can be in charge of the page and
approve/add the new CSAF info when a request from an organization is
received.

Thanks,

--Feng

On 7/12/2021 4:55 PM, Schmidt, Thomas wrote:
> 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://urldefense.com/v3/__https://github.com/oasis-tcs/csaf/pull/290__;!!ACWV5N9M2RV99hQ!a71VyHtiyQg2EVyuCJ4gvBYmy2Q7vH7_BPWlmUtx6eXsPFlpH0Drho0xkYFp21M$ . 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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://urldefense.com/v3/__https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php__;!!ACWV5N9M2RV99hQ!a71VyHtiyQg2EVyuCJ4gvBYmy2Q7vH7_BPWlmUtx6eXsPFlpH0Drho0x8w6TgjU$ 
>