RFD for Assertion Framework

[jayjacobs]

This RFD introduces a definition-driven Assertion Framework to make CVE data more machine-usable while reducing schema churn and downstream consumer processing burden. The framework adds a new, optional “assertions” field to the CNA (and ADP) container. Each assertion group is a small, regular, schema-validated structure whose keys and value constraints are governed by a referenced, versioned Assertion Definition Document.

[sei-vsarvepalli]

Some points to consider post meeting on Jan 15 1600 hrs.

1. For all dates, use RFC3339 instead of ISO 8601 as a standard for more strict/tight definition of date timestamp.
2. Consider assertions.items.value to be values as an array allowing for an assertion (or an evaluation) performed by an analyst has provided can be more than one - more like a negation where an assertions states exploitation is NOT None but can be PoC or Active for example with the SSVC example where exploitation item can have three potential values ["None", "PoC" , "Active"] - all the analyst knows is that Exploitation is not None but wants to pass on that information.
3. The assertions.definition.url should it be a required permalink and should we use this URL to dynamicallyverify the CVE submission by CVE Services. This could mean operational impact on having to dynamically verify the incoming assertions - may or may be viable. The schema is very much like embedded schema or $ref like idea in JSON allowing for some complexity in schema setup, This may also complicate test cases if they are entirely open-ended for programatic verification.
4. Related to the above, should the accepted namespace (and version) itself be an enum field cvss ssvc cisa limited to well-known providers who can follow certain test cases and they will be added to the namespace enum? to should it be entirely open-ended?
5. Will the metrics assertions data provided by the CNA support multiple languages? Related to will the namespace be restricted or verified? for example assertions[].items[].key is always expected in US English "en" or can it be in other languages? In our SSVC namespace of ssvc/jp-JP the decision point definition 攻撃の自動化可否 is an accepted field.