[Servercert-wg] Ballot SC39v3: Definition of Critical Vulnerability

[Neil Dunbar]

The issue here was to remove ambiguity in the NCSSRs as a starting 
position.

I don't for a second doubt that there are many ways to make the 
vulnerability curing process more thorough and transparent, but this 
ballot in particular was simply to correct an incorrect URI in the 
definitions and then to pin down what CVSS version should be referenced 
in order to trigger the Critical Vulnerability patch window.

You are, of course, correct when you state that that patching is not the 
only solution - indeed, the NCSSRs do define a process by which a CA can 
say "We're not going to patch this because <reasons>". It's not very 
transparent, and it can certainly be improved. But this particular 
ballot was just there to patch an error which had developed in the text.

The NetSec team are more than happy to receive submissions on how to 
improve the patching process!

Thanks,

Neil

On 19/01/2021 15:54, Weiler, Nathalie wrote:
> Dear Neil, dear all,
>
> While following the discussion on this editorial change now for a while, I still wonder what the expected benefit for the community is. I guess the main goal should be that we get a way on how we patch or remediate vulnerable and exploitable components in the CA ecoysytem in a verifiable way.
> Using a public vulnerability rating is certainly one essential part in this procedure, but by far not the only one. Exploitability also plays a major role. And finally, there are often multiple ways on fixing the issue, not only patching the component to maybe inexistent "secure" patch.
> Why do we not spend our time on defining the procedure correctly instead of patching the wording for the sake of the correctness of reference?
>
>   Best regards,
>
>   Nathalie
>
> On 19.01.21, 15:39, "Servercert-wg on behalf of Neil Dunbar via Servercert-wg" <servercert-wg-bounces at cabforum.org on behalf of servercert-wg at cabforum.org> wrote:
>
>      Colleagues,
>
>      I'm continuing the discussion period for SC39 (now at version 3), per
>      the text below. As before, I've attached the discussion document to this
>      email for background information. The principal change is to lock the
>      version of the CVSS in at 2.0, while retaining the "critical" threshold
>      at 7.0. This removes the ambiguity as to which CVSS score should apply
>      to define a critical vulnerability.
>
>      There are other issues surrounding vulnerability patching to be
>      addressed, but this ballot was only ever supposed to be an editorial
>      change, rather than describe additional practices.
>
>      The following motion has been proposed by Neil Dunbar of TrustCor and
>      endorsed by Ben Wilson (Mozilla) and Corey Bonnel (DigiCert).
>
>      Purpose of Ballot:
>
>      It was brought to the attention of the NetSec Subgroup that the URL in
>      the NCSSRs which points to the definitions of the CVSS security scoring
>      system is no longer the appropriate one; moreover the definition of
>      “Critical Vulnerability” is no longer strictly correct by the
>      definitions currently posted by NIST.
>
>      Definitions of terms should always be consistent, especially when the
>      term is canonically defined by an external body; references should be
>      updated as and when they change on the canonical source.
>
>      -- MOTION BEGINS --
>
>      This ballot modifies the “Network and Certificate System Security
>      Requirements” based on Version 1.5.
>
>      Under the section “Definitions”:
>
>      Remove the current definition:
>
>      Critical Vulnerability: A system vulnerability that has a CVSS score of
>      7.0 or higher according to the NVD or an equivalent to such CVSS rating
>      (see http://nvd.nist.gov/home.cfm), or as otherwise designated as a
>      Critical Vulnerability by the CA or the CA/Browser Forum.
>      Insert a new definition:
>
>      Critical Vulnerability: A system vulnerability that has a CVSS v2.0
>      score of 7.0 or higher according to the NVD or an equivalent to such
>      CVSS rating (see https://nvd.nist.gov/vuln-metrics/cvss), or as
>      otherwise designated as a Critical Vulnerability by the CA or the
>      CA/Browser Forum.
>
>      -- MOTION ENDS --
>
>      * WARNING *: USE AT YOUR OWN RISK. THE REDLINE BELOW IS NOT THE OFFICIAL
>      VERSION OF THE CHANGES (CABF Bylaws, Section 2.4(a)):
>
>      A comparison of the changes can be found at:
>
>      https://github.com/cabforum/servercert/compare/2b7720f...neildunbar:61fd381?diff=split
>
>      This ballot proposes one Final Maintenance Guideline.
>
>      The procedure for approval of this ballot is as follows:
>
>      Discussion:  (7+ days)
>      Start Time: 2021-01-19 17:00 UTC
>      End Time:  not before 2021-01-26 17:00 UTC
>
>      Vote for approval    (7 days)
>      Start Time: TBD
>      End Time: TBD
>
>      Regards,
>
>      Neil
>
>