OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

csaf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (CSAF-28) Proposal for CVSS future embrace


    [ https://issues.oasis-open.org/browse/CSAF-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=65994#comment-65994 ] 

Stefan Hagen commented on CSAF-28:
----------------------------------

Updated the proposal to decouple from specific cvss schema namespaces (there are no generic ones offered, that provide the [0.0, 10.0] score type. I suggest the members of the committee encourage the editor to use this changed schema to provide an updated draft two weeks before the end of May meeting, so that the committee members could ideally push this version as CSD01 into public review.

> Proposal for CVSS future embrace
> --------------------------------
>
>                 Key: CSAF-28
>                 URL: https://issues.oasis-open.org/browse/CSAF-28
>             Project: OASIS Common Security Advisory Framework (CSAF) TC
>          Issue Type: Improvement
>         Environment: [Proposed]
>            Reporter: Stefan Hagen
>            Priority: Critical
>
> Originally proposed in a mail to the TC list (archived for public access at https://lists.oasis-open.org/archives/csaf/201704/msg00040.html ):
> Better represent the transitive task of embedding and relating CVSS information of various versions. 
> Ideally the CVSS elements are valid CVSS "documents" themselves, but having read through many real world CVRF v1.1 documents they are (often understandably so) not.
> Either CVSS v3 content is tunneld throught the CVRF v1.1 ScoreSet element (which suits a CVSS v2 content model) and this version info is noted out of band (say in some web page of publisher domain or the CVSS v3 vector is stored without the fixed prefix (required by CVSS v3) to safe space in the length constraint of the CVRF v1.1 Vector element.
> To a) mitigate the current discussion on the cardinalities of elements for storage of CVSS v2 and v3 content and b) avoid clumsy model names and c) be future proof to a reasonable extent without introducing an xs:any black hole a version attributed superset ScoreSet element is suggested.
> Please note, that currently the per CVSSv3 required fixed prefix for vectors is not always 
> used "in the wild" (and understandably so, as our cvrf v1.1 length might forbid legitimate values in CVSS v3.
> So a Version attribute on a single ScoreSet element instance might be an enhancement for existing documents
> when being transformed (see the Oracle example, where the CVSS3.0 prefix would now be signalled
> via the Version attribute value "3".
> Any feedback greatly appreciated esp. practical problems not known to me in my tower of thought 



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]