OASIS Common Security Advisory Framework (CSAF) TC

Dear Members, to enable a clearly documented decision on this crucial question if we enforce CVSSv3 scoring with CSAF CVRF v1.2, I move, that the chair of the TC shall request a ballot for a full majority vote from administration with the ballot question: "Every vuln:CVSSScoreSets element if present MUST contain zero or more CVSSScoreSetV2 and one or more CVSSScoreSetV3 elements" offering the answers "yes", "no", and "abstain". Please find below details on past and current (not yet decided) cardinalities ... On 04/04/17 21:01, Art Manion wrote: > I'm going to try to summarize the discussion about the use of CVSS > v2/v3, with the goal of creating a motion or voting position if needed. > > < https://issues.oasis-open.org/browse/CSAF-21?focusedCommentId=65728&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-65728 > > > I read the above comment, but am still confused (it's me, not you > Stefan), so I'm going to start with what I think should happen: > > A CVRF document contains 1 or more vulnerabilities > A vulnerability contains 0 or 1 CVSSv2 scores > A vulnerability contains 0 or 1 CVSSv3 scores > > CVSSv2 or v3 scores must follow CVSS rules and contain a complete set of > Base vectors and score. Temporal, environmental (or modified base) are > optional. Inside vuln.xsd v1.1 and in the contributed initial v1.2 draft from Feng the following cardinalities apply: ScoreSet [1, infty] (v1.1), ScoreSetV2 [0, infty] and ScoreSetV3 [?, infty] (both v1.2) MUST contain exactly one BaseScore (v1.1), BaseScoreV2 and BaseScoreV3 respectively (both v1.2) AND ScoreSet (v1.1), ScoreSetV2 and ScoreSetV3 (both v1.2) contain [0, 1] TemporalScore (v1.1), TemporalScoreV2 and TemporalScoreV3 respectively (both v1.2) AND ScoreSet (v1.1), ScoreSetV2 and ScoreSetV3 (both v1.2) contain [0, 1] EnvironmentalScore (v1.1), EnvironmentalScoreV2 and EnvironmentalScoreV3 respectively (both v1.2) AND ScoreSet (v1.1), ScoreSetV2 and ScoreSetV3 (both v1.2) contain [0, 1] Vector (v1.1), VectorV2 and VectorV3 respectively (both v1.2) AND ScoreSet (v1.1), ScoreSetV2 and ScoreSetV3 (both v1.2) contain [0, infty] vuln:ProductID (in any version I guess) So the Vectors are optional in every variant! > I believe Feng's position is that if a vulnerability has a CVSS score, > it must be CVSSv3 (or must have CVSSv3 and can optionally also include > CVSSv2?). If a CVRF producer wants to use CVSSv2, they should use CVRF 1.1. > This is what I noted in the comment as my understanding, but have no other feedback received, and think this was made clear by Feng. /Stefan

On 04/04/2017, at 13:31 PM, Mr. Stefan Hagen wrote: Dear Members, to enable a clearly documented decision on this crucial question if we enforce CVSSv3 scoring with CSAF CVRF v1.2, I move, that the chair of the TC shall request a ballot for a full majority vote from administration with the ballot question: "Every vuln:CVSSScoreSets element if present MUST contain zero or more CVSSScoreSetV2 and one or more CVSSScoreSetV3 elements" offering the answers "yes", "no", and "abstain". How do we vote on this or are we waiting for the next meeting? I think the above is reasonable and would vote for it. Please find below details on past and current (not yet decided) cardinalities ... On 04/04/17 21:01, Art Manion wrote: I'm going to try to summarize the discussion about the use of CVSS v2/v3, with the goal of creating a motion or voting position if needed. < https://issues.oasis-open.org/browse/CSAF-21?focusedCommentId=65728&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-65728 > I read the above comment, but am still confused (it's me, not you Stefan), so I'm going to start with what I think should happen: A CVRF document contains 1 or more vulnerabilities A vulnerability contains 0 or 1 CVSSv2 scores A vulnerability contains 0 or 1 CVSSv3 scores CVSSv2 or v3 scores must follow CVSS rules and contain a complete set of Base vectors and score. Temporal, environmental (or modified base) are optional. Inside vuln.xsd v1.1 and in the contributed initial v1.2 draft from Feng the following cardinalities apply: ScoreSet [1, infty] (v1.1), ScoreSetV2 [0, infty] and ScoreSetV3 [?, infty] (both v1.2) MUST contain exactly one BaseScore (v1.1), BaseScoreV2 and BaseScoreV3 respectively (both v1.2) AND ScoreSet (v1.1), ScoreSetV2 and ScoreSetV3 (both v1.2) contain [0, 1] TemporalScore (v1.1), TemporalScoreV2 and TemporalScoreV3 respectively (both v1.2) AND ScoreSet (v1.1), ScoreSetV2 and ScoreSetV3 (both v1.2) contain [0, 1] EnvironmentalScore (v1.1), EnvironmentalScoreV2 and EnvironmentalScoreV3 respectively (both v1.2) AND ScoreSet (v1.1), ScoreSetV2 and ScoreSetV3 (both v1.2) contain [0, 1] Vector (v1.1), VectorV2 and VectorV3 respectively (both v1.2) AND ScoreSet (v1.1), ScoreSetV2 and ScoreSetV3 (both v1.2) contain [0, infty] vuln:ProductID (in any version I guess) So the Vectors are optional in every variant! I believe Feng's position is that if a vulnerability has a CVSS score, it must be CVSSv3 (or must have CVSSv3 and can optionally also include CVSSv2?). If a CVRF producer wants to use CVSSv2, they should use CVRF 1.1. This is what I noted in the comment as my understanding, but have no other feedback received, and think this was made clear by Feng. /Stefan -- Vincent Danen / Red Hat Product Security

Before voting can we have an opportunity to discuss? I am not sure everyone is aware of the consequences of the various options. The proposal as written, if accepted, would require anyone who wish to provide data for vulnerabilities without CVSS v3.0 scores in the CVRF 1.1 format only and they would not be able to use the CVRF 1.2 format if they wish to share CVSS v2.0 scores. For data providers which have data on both new and old vulnerabilities it would require them (and their consumers) to use both CVRF 1.1 and 1.2. I see the restriction that one must always provide a CVSS v3.0 score when providing a score an unnecessary restriction on the format and limits the use cases for which this format could be used. Regards, -Harold -----Original Message----- From: csaf@lists.oasis-open.org [ mailto:csaf@lists.oasis-open.org ] On Behalf Of Vincent Danen Sent: Tuesday, April 04, 2017 4:10 PM To: Mr. Stefan Hagen <stefan@hagen.link> Cc: csaf@lists.oasis-open.org Subject: Re: [csaf] CVSS v2/v3 use in CVRF 1.2 On 04/04/2017, at 13:31 PM, Mr. Stefan Hagen wrote: > Dear Members, to enable a clearly documented decision on this crucial > question if we enforce CVSSv3 scoring with CSAF CVRF v1.2, > > I move, that the chair of the TC shall request a ballot for a full > majority vote from administration with the ballot question: "Every > vuln:CVSSScoreSets element if present MUST contain zero or more > CVSSScoreSetV2 and one or more CVSSScoreSetV3 elements" offering the > answers "yes", "no", and "abstain". How do we vote on this or are we waiting for the next meeting? I think the above is reasonable and would vote for it. > Please find below details on past and current (not yet decided) > cardinalities ... > > > On 04/04/17 21:01, Art Manion wrote: >> I'm going to try to summarize the discussion about the use of CVSS >> v2/v3, with the goal of creating a motion or voting position if >> needed. >> >> < https://issues.oasis-open.org/browse/CSAF-21?focusedCommentId=65728& ; >> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel >> #comment-65728> >> >> I read the above comment, but am still confused (it's me, not you >> Stefan), so I'm going to start with what I think should happen: >> >> A CVRF document contains 1 or more vulnerabilities A vulnerability >> contains 0 or 1 CVSSv2 scores A vulnerability contains 0 or 1 CVSSv3 >> scores >> >> CVSSv2 or v3 scores must follow CVSS rules and contain a complete set >> of Base vectors and score. Temporal, environmental (or modified >> base) are optional. > > Inside vuln.xsd v1.1 and in the contributed initial v1.2 draft from > Feng the following cardinalities apply: > > ScoreSet [1, infty] (v1.1), ScoreSetV2 [0, infty] and ScoreSetV3 [?, > infty] (both v1.2) MUST contain exactly one BaseScore (v1.1), > BaseScoreV2 and BaseScoreV3 respectively (both v1.2) > > AND > > ScoreSet (v1.1), ScoreSetV2 and ScoreSetV3 (both v1.2) contain [0, 1] > TemporalScore (v1.1), TemporalScoreV2 and TemporalScoreV3 respectively > (both v1.2) > > AND > > ScoreSet (v1.1), ScoreSetV2 and ScoreSetV3 (both v1.2) contain [0, 1] > EnvironmentalScore (v1.1), EnvironmentalScoreV2 and > EnvironmentalScoreV3 respectively (both v1.2) > > AND > > ScoreSet (v1.1), ScoreSetV2 and ScoreSetV3 (both v1.2) contain [0, 1] > Vector (v1.1), VectorV2 and VectorV3 respectively (both v1.2) > > AND > > ScoreSet (v1.1), ScoreSetV2 and ScoreSetV3 (both v1.2) contain [0, > infty] vuln:ProductID (in any version I guess) > > So the Vectors are optional in every variant! > > >> I believe Feng's position is that if a vulnerability has a CVSS >> score, it must be CVSSv3 (or must have CVSSv3 and can optionally also >> include CVSSv2?). If a CVRF producer wants to use CVSSv2, they >> should use CVRF 1.1. >> > > This is what I noted in the comment as my understanding, but have no > other feedback received, and think this was made clear by Feng. > > > /Stefan -- Vincent Danen / Red Hat Product Security --------------------------------------------------------------------- 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://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

On Tue, Apr 4, 2017 at 1:19 PM, Booth, Harold (Fed) < harold.booth@nist.gov > wrote: Before voting can we have an opportunity to discuss? I am not sure everyone is aware of the consequences of the various options. (If following the rules of Robert's Rules of order, discussion isn't supposed to happen unless there's an open motion. In practice, I haven't seen that much in OASIS-TCs.)   The proposal as written, if accepted, would require anyone who wish to provide data for vulnerabilities without CVSS v3.0 scores in the CVRF 1.1 format only and they would not be able to use the CVRF 1.2 format if they wish to share CVSS v2.0 scores. For data providers which have data on both new and old vulnerabilities it would require them (and their consumers) to use both CVRF 1.1 and 1.2. I see the restriction that one must always provide a CVSS v3.0 score when providing a score an unnecessary restriction on the format and limits the use cases for which this format could be used. I don't have a position on the compatibility question, as I don't think I or my company have a need to support 1.1 format. If 1.2 is incompatible with 1.1 (as it appears it is), then any clients that need to support 1.1 documents will have to support both 1.1 & 1.2 formats. Either that, or we have to figure out a compatibility mode for 1.1 documents. For compatibility, pne option is to add a "Legacy" indication of some kind to the XML model. With that model the legacy element would you allow either only a CVSSv2 score, or no score whatsoever. Instead of CVSSScoreSets as currently spec'd, it could be "CVSSScoreSets" or "LegacyCVSSScoreSets", which has a content model that only allows zero or one CVSSv2 scores.... The content model for Vulnerability would change to allow just one of CVSSScoreSets or LegacyCVSSScoreSets. Again, I have no position on this. Seems like the choice comes down to supporting seamless migration of 1.1 format to 1.2 format or not. Eric.   Regards, -Harold -----Original Message----- From: csaf@lists.oasis-open.org [mailto: csaf@lists.oasis-open. org ] On Behalf Of Vincent Danen Sent: Tuesday, April 04, 2017 4:10 PM To: Mr. Stefan Hagen <stefan@hagen.link> Cc: csaf@lists.oasis-open.org Subject: Re: [csaf] CVSS v2/v3 use in CVRF 1.2 On 04/04/2017, at 13:31 PM, Mr. Stefan Hagen wrote: > Dear Members, to enable a clearly documented decision on this crucial > question if we enforce CVSSv3 scoring with CSAF CVRF v1.2, > > I move, that the chair of the TC shall request a ballot for a full > majority vote from administration with the ballot question: "Every > vuln:CVSSScoreSets element if present MUST contain zero or more > CVSSScoreSetV2 and one or more CVSSScoreSetV3 elements" offering the > answers "yes", "no", and "abstain". How do we vote on this or are we waiting for the next meeting?  I think the above is reasonable and would vote for it. > Please find below details on past and current (not yet decided) > cardinalities ... > > > On 04/04/17 21:01, Art Manion wrote: >> I'm going to try to summarize the discussion about the use of CVSS >> v2/v3, with the goal of creating a motion or voting position if >> needed. >> >> < https://issues.oasis-open.org /browse/CSAF-21?focusedComment Id=65728& >> page=com.atlassian.jira.plugin .system.issuetabpanels:comment -tabpanel >> #comment-65728> >> >> I read the above comment, but am still confused (it's me, not you >> Stefan), so I'm going to start with what I think should happen: >> >> A CVRF document contains 1 or more vulnerabilities A vulnerability >> contains 0 or 1 CVSSv2 scores A vulnerability contains 0 or 1 CVSSv3 >> scores >> >> CVSSv2 or v3 scores must follow CVSS rules and contain a complete set >> of Base vectors and score.  Temporal, environmental (or modified >> base) are optional. > > Inside vuln.xsd v1.1 and in the contributed initial v1.2 draft from > Feng the following cardinalities apply: > > ScoreSet [1, infty] (v1.1), ScoreSetV2 [0, infty] and ScoreSetV3 [?, > infty] (both v1.2) MUST contain exactly one BaseScore (v1.1), > BaseScoreV2 and BaseScoreV3 respectively (both v1.2) > > AND > > ScoreSet (v1.1), ScoreSetV2 and ScoreSetV3 (both v1.2) contain [0, 1] > TemporalScore (v1.1), TemporalScoreV2 and TemporalScoreV3 respectively > (both v1.2) > > AND > > ScoreSet (v1.1), ScoreSetV2 and ScoreSetV3 (both v1.2) contain [0, 1] > EnvironmentalScore (v1.1), EnvironmentalScoreV2 and > EnvironmentalScoreV3 respectively (both v1.2) > > AND > > ScoreSet (v1.1), ScoreSetV2 and ScoreSetV3 (both v1.2) contain [0, 1] > Vector (v1.1), VectorV2 and VectorV3 respectively (both v1.2) > > AND > > ScoreSet (v1.1), ScoreSetV2 and ScoreSetV3 (both v1.2) contain [0, > infty] vuln:ProductID (in any version I guess) > > So the Vectors are optional in every variant! > > >> I believe Feng's position is that if a vulnerability has a CVSS >> score, it must be CVSSv3 (or must have CVSSv3 and can optionally also >> include CVSSv2?).  If a CVRF producer wants to use CVSSv2, they >> should use CVRF 1.1. >> > > This is what I noted in the comment as my understanding, but have no > other feedback received, and think this was made clear by Feng. > > > /Stefan -- Vincent Danen / Red Hat Product Security ------------------------------ ------------------------------ --------- 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://www.oasis-open.org/app s/org/workgroup/portal/my_work groups.php ------------------------------ ------------------------------ --------- 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://www.oasis-open.org/app s/org/workgroup/portal/my_work groups.php

Re: Before voting can we have an opportunity to discuss? I am not sure everyone is aware of the consequences of the various options. I think Harold raises a good point.  It's important those voting on a formal ballot understand the ramifications of their decision. I'm not familiar enough with all of the practical implementation details, but want to pose the following question: In the CTI TC community we've faced similar issues with backwards compatibility (and about to face a major challenge in the XML => JSON MTI transition).  MITRE was engaged to develop conversion/validation scripts.  This provided a clean method to convert legacy STIX documents to the current version.  If you still have old operational tooling (or legacy data files) you can add an automated process to upgrade your content.  It only works in one direction of course and you may have to manually deal with outliers/special cases. Would this be a viable approach here as well? Patrick Maroney Principle Engineer - Data Science & Analytics Wapack Labs On Apr 4, 2017, at 4:19 PM, Booth, Harold (Fed) < harold.booth@nist.gov > wrote: Before voting can we have an opportunity to discuss? I am not sure everyone is aware of the consequences of the various options.

On 2017-04-04 15:31, Mr. Stefan Hagen wrote: > I move, that the chair of the TC shall request a ballot for a full > majority vote from administration with the ballot question: "Every > vuln:CVSSScoreSets element if present MUST contain zero or more > CVSSScoreSetV2 and one or more CVSSScoreSetV3 elements" offering the > answers "yes", "no", and "abstain". Assuming discussion is allowed at this point... How can a vuln:CVSSScoreSets element have more than one CVSSScoreSet? This means a vulnerability can have two or more CVSS scores? Can anyone provide a use case/example? Thanks, - Art

On 04/04/2017, at 20:06 PM, Art Manion wrote: On 2017-04-04 15:31, Mr. Stefan Hagen wrote: I move, that the chair of the TC shall request a ballot for a full majority vote from administration with the ballot question: "Every vuln:CVSSScoreSets element if present MUST contain zero or more CVSSScoreSetV2 and one or more CVSSScoreSetV3 elements" offering the answers "yes", "no", and "abstain". Assuming discussion is allowed at this point... How can a vuln:CVSSScoreSets element have more than one CVSSScoreSet? This means a vulnerability can have two or more CVSS scores? Can anyone provide a use case/example? My understanding is you can have both CVSSv2 and CVSSv3, which qualifies for multiple scores. With respect to the comments about CVRF 1.1 vs 1.2, given CVSSv3 support is the only scoped change (correct?) it doesn't seem like it would be a problem to require a CVSSv3 score and, optionally, a CVSSv2 score. If you want to use CVSSv2 as the default, keep using 1.1. If you intend to use CVSSv3, use 1.2. I can't see someone opting to default to v2 and optionally include v3 if they're already deciding to use v3 in some way (as I don't see any advantage in v2 over v3). But that is just my opinion. I'm content with minimum one score, either v2 OR v3, meaning you can default to whichever you prefer. -- Vincent Danen / Red Hat Product Security

So here is a use case: Let's say you have vulnerability data spanning multiple years. And this data has varying degrees of age and analysis and several thousand entries have CVSSv2 and CVSSv3 scores and tens of thousands of entries have CVSSv2 only. You wish to provide all of your data in a single format so your end-users do not need to parse/process different formats. CVRF 1.1 does not work for everything because it cannot support CVSSv3. How do you expect to deliver in a single format to your end-users if CVRF 1.2 requires CVSSv3 scores? While I do understand the thinking around requiring CVSS v3 in CVRF 1.2, I see it as overly focusing on the single use case of describing new vulnerabilities from this time forward and not taking into account other use cases and usage models. -----Original Message----- From: csaf@lists.oasis-open.org [ mailto:csaf@lists.oasis-open.org ] On Behalf Of Vincent Danen Sent: Wednesday, April 05, 2017 3:01 PM To: Art Manion <amanion@cert.org> Cc: Mr. Stefan Hagen <stefan@hagen.link>; csaf@lists.oasis-open.org Subject: Re: [csaf] CVSS v2/v3 use in CVRF 1.2 On 04/04/2017, at 20:06 PM, Art Manion wrote: > On 2017-04-04 15:31, Mr. Stefan Hagen wrote: > >> I move, that the chair of the TC shall request a ballot for a full >> majority vote from administration with the ballot question: "Every >> vuln:CVSSScoreSets element if present MUST contain zero or more >> CVSSScoreSetV2 and one or more CVSSScoreSetV3 elements" offering the >> answers "yes", "no", and "abstain". > > Assuming discussion is allowed at this point... > > How can a vuln:CVSSScoreSets element have more than one CVSSScoreSet? > This means a vulnerability can have two or more CVSS scores? Can > anyone provide a use case/example? My understanding is you can have both CVSSv2 and CVSSv3, which qualifies for multiple scores. With respect to the comments about CVRF 1.1 vs 1.2, given CVSSv3 support is the only scoped change (correct?) it doesn't seem like it would be a problem to require a CVSSv3 score and, optionally, a CVSSv2 score. If you want to use CVSSv2 as the default, keep using 1.1. If you intend to use CVSSv3, use 1.2. I can't see someone opting to default to v2 and optionally include v3 if they're already deciding to use v3 in some way (as I don't see any advantage in v2 over v3). But that is just my opinion. I'm content with minimum one score, either v2 OR v3, meaning you can default to whichever you prefer. -- Vincent Danen / Red Hat Product Security --------------------------------------------------------------------- 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://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

On 4/5/17 4:29 PM, Booth, Harold (Fed) wrote: > While I do understand the thinking around requiring CVSS v3 in CVRF > 1.2, I see it as overly focusing on the single use case of describing > new vulnerabilities from this time forward and not taking into > account other use cases and usage models. For CERT/CC's use case -- attempting to evaluate internet-wide severity -- CVSSv2 is superior due to the way Environmental metrics are handled. Furthermore, CVSS has other issues, and I intend to bring up alternatives, or at least some sort of modular/container severity object, for CSAF/CVRF v.next. Regards, - Art

On 4/5/17 3:00 PM, Vincent Danen wrote: >> How can a vuln:CVSSScoreSets element have more than one CVSSScoreSet? >> This means a vulnerability can have two or more CVSS scores? Can >> anyone >> provide a use case/example? > My understanding is you can have both CVSSv2 and CVSSv3, which qualifies > for multiple scores. One v2 and one v3 score seems reasonable, what I'm wondering about is a vulnerability having two or more v2 scores (or v3 scores). Multiple same-version CVSS scores. - Art

On 04/05/2017, at 17:37 PM, Art Manion wrote: On 4/5/17 3:00 PM, Vincent Danen wrote: How can a vuln:CVSSScoreSets element have more than one CVSSScoreSet? This means a vulnerability can have two or more CVSS scores? Can anyone provide a use case/example? My understanding is you can have both CVSSv2 and CVSSv3, which qualifies for multiple scores. One v2 and one v3 score seems reasonable, what I'm wondering about is a vulnerability having two or more v2 scores (or v3 scores). Multiple same-version CVSS scores. This shouldn't be an issue unless it's tied to temporal or environmental metrics, correct? Or, where CVSS becomes a bit weak, related to product usage of that piece of software. It would almost be as though you need to be able to associate a score to a product or component (for instance we might say CVE-X affects openstack in this way resulting in this score, but affects RHEL in this other way resulting in a different score). This is something we probably want to look at for CSAF 2.0, not CVRF 1.2. I don't think it can be resolved easily. You could have 12 different CVSSv2 scores right now but it's almost pointless if you can't map that back to a particular product or scenario. -- Vincent Danen / Red Hat Product Security

On 2017-04-12 14:35, Vincent Danen wrote: > This is something we probably want to look at for CSAF 2.0, not CVRF > 1.2. I don't think it can be resolved easily. You could have 12 > different CVSSv2 scores right now but it's almost pointless if you can't > map that back to a particular product or scenario. Agreed. Thus, I'm proposing that CVRF 1.2 should allow zero or one CVSS v2 score and zero or one CVSS v3 score. A separate question remains: If there is a CVSS score, must it be v3 (and have an optional single v2 score)? My position is that the score can be either v2 or v3 (or both). - Art

- zero or one CVSSv2 and zero or one CVSSv3 - recommendation: either v2 or v3 (or both) because sometimes I would like to publish advisory without scores. at first, wish to advertise threat to the Internet. Next, evaluate the detail of vulnerability with scores. BR Masato On 2017/04/13 11:47, Art Manion wrote: > On 2017-04-12 14:35, Vincent Danen wrote: > >> This is something we probably want to look at for CSAF 2.0, not CVRF >> 1.2. I don't think it can be resolved easily. You could have 12 >> different CVSSv2 scores right now but it's almost pointless if you can't >> map that back to a particular product or scenario. > > Agreed. Thus, I'm proposing that CVRF 1.2 should allow zero or one CVSS > v2 score and zero or one CVSS v3 score. > > A separate question remains: If there is a CVSS score, must it be v3 > (and have an optional single v2 score)? My position is that the score > can be either v2 or v3 (or both). > > - Art > > --------------------------------------------------------------------- > 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://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > -- ------------------------------------------------------------------ http://www.hitachi.com/hirt/ http://jvnrss.ise.chuo-u.ac.jp/%7Emasato/eprofile.html ------------------------------------------------------------------ Masato Terada <masato.terada.rd@hitachi.com> KeyID: 0x1A288D8C EA94 E888 84A9 28B0 7BFD D1A5 3E9E 3C73 1A28 8D8C Hitachi Incident Response Team <hirt@hitachi.co.jp>, Hitachi Ltd. Hitachi Omori 2nd Bldg. 10F 6-27-18 Minamioi, Shinagawa, Tokyo, Japan 140-8572 Tel: +81 44 555 0894 Fax: Mobile: +81 90 4369 3601

I am in general agreement with the concept of zero or one score for each CVSS version. However, to avoid revisiting this should a CVSS v4 appear, it might be simpler to say zero or one score for each CVSS version at or above v2. On Wed, Apr 12, 2017 at 7:47 PM, Art Manion < amanion@cert.org > wrote: Agreed.  Thus, I'm proposing that CVRF 1.2 should allow zero or one CVSS v2 score and zero or one CVSS v3 score. A separate question remains:  If there is a CVSS score, must it be v3 (and have an optional single v2 score)?  My position is that the score can be either v2 or v3 (or both).

On 04/18/2017, at 18:36 PM, Denny Page wrote: I am in general agreement with the concept of zero or one score for each CVSS version. However, to avoid revisiting this should a CVSS v4 appear, it might be simpler to say zero or one score for each CVSS version at or above v2. Slow response here but yes, in agreement with this. It should be acceptable to have no scores, or for the industrious, to have every score. On Wed, Apr 12, 2017 at 7:47 PM, Art Manion <amanion@cert.org> wrote: Agreed. Thus, I'm proposing that CVRF 1.2 should allow zero or one CVSS v2 score and zero or one CVSS v3 score. A separate question remains: If there is a CVSS score, must it be v3 (and have an optional single v2 score)? My position is that the score can be either v2 or v3 (or both). -- Vincent Danen / Red Hat Product Security