Hi Thomas, > On 7 Mar 2023, at 16:38, Schmidt, Thomas <thomas.schmidt@xxxxxxxxxxx> wrote: > > 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. This is correct. > > 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. This would duplicate the functionality of the content-type header. That’s not good because ours will not be the only discovery mechanism. Furthermore, having an additional data element may lead to more configuration errors, when the element points to one type, but another is returned. I think the right thing to do here is to provide advice. In particular, we should note that web servers are advised return application/json, and that consumers are advised to take care about how they interpret such information, that if they choose to query elements to determine what a JSON object is, they should choose those elements that are authoritative within the definition of those specifications. For instance: Document->csaf_version => CSAF (and its appropriate version). spdx->version => SPDX There may be some formats where that simply isn’t possible, but the right thing to do, then, is to send the correct mime-type in response to an HTTP query. Another thing I should mention is that we probably at least mention JSON sequences for certain types, as potential return values, but it is left to the content owner to request appropriate the IANA {application}+json-seq value. Eliot -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
