Dear colleagues, I' still struggling with the "vuln-url" as it might be a little bit too open to be really useful: > "A statically located URL that references vulnerability information" This could also point to a vendor website, where the vendor publishes human-readable security advisories. Reading the draft I get the feeling (and please correct me if I overlooked something) that the intended use is machine-readable data. Assuming that the data is machine-readable, there is a second problem: It is actually unclear for the consumer, which data format will be returned by the `cloud`. The content-type header might not be helpful here as multiple formats are JSON - and therefore a webserver in its default state would return the same content-type 'application/json'. For CSAF, and I pick that standard as this is the one I'm most familiar with, one could argue that a ROLIE feed (see example 130: https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#7115-requirement-15-rolie-feed) references vulnerability information. At the moment, most PSIRTs and other issuing parties write advisories per event (e.g. as a part of a vulnerability disclosure), not per product. IMHO, the easiest way for them would be, if the static URL may contain a list of advisories. Then they would just add new advisories that apply to the product with that URL to the list residing at the URL. Therefore, I suggest to add an entry "vuln-format" adjacent the "vuln-url". This field MUST be present, if "vuln-url" is there and MUST contain a reference (URI) to the format of the content, e.g. - https://docs.oasis-open.org/csaf/csaf/v2.0/os/schemas/csaf_json_schema.json for a single CSAF file - https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#52-separation-in-data-stream for a datastream of CSAF files - https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#7115-requirement-15-rolie-feed for a ROLIE feed with CSAF files - https://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/cs01/csaf-cvrf-v1.2-cs01.html for CVRF 1.2 for CVRF 1.2 - http://www.icasi.org/the-common-vulnerability-reporting-framework-cvrf-v1-1/ for CVRF 1.1 - https://html.spec.whatwg.org/ for HTML (if you want to allow human-readable information) - https://www.iso.org/standard/75839.html for pdf (if you want to allow human-readable information) - ... (Of course the list should be extensible.) Applications can then use this field to select the correct parsing method. The draft should be extended with examples to reflect these changes... Best regards, Thomas Schmidt -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
