<div dir="ltr"><div>Hi Neil,</div><div><br></div><div>Just capturing on the list some of the discussion.</div><div><br></div><div>One of the significant changes here is this meaningfully reduces the security of the ecosystem, by moving the window in which CAs need to patch from CVSS scores of 7.0 to the much more rarer 9.0. During the call, it was highlighted that CVSS 1.0 only had three levels (Low, Medium, and High), with the CA/B Forum determining that any thing at High or above (7.0+) was, in fact, Critical for CA systems. This new ballot reduces security, although perhaps unintentionally, by determining that the only Critical bugs to CA systems are those that CVSS 3.0, which has four levels (Low, Medium, High, Critical), deems as critical; that is, 9.0+</div><div><br></div><div>As discussed, and obviously captured above, this seems like a step backwards for security, and there did not seem to be a compelling reason to allow CAs an additional 6+ months of patch time simply to align the terminology. For example, this ballot could redefine "Critical Vulnerability" to "High-Risk Vulnerability", in order to align terminology. Alternatively, we could continue with acknowledging that Critical Vulnerabilities are, due to CAs special nature, anything that is High or above.</div><div><br></div><div>There was some suggestion that 96 hours is too short a window to address these events, but we also discussed how, for better or worse, the NCSSRs afford significant, non-transparent leeway to CAs to ignore such patch requirements, by simply requiring CAs either "Create and implement a plan to mitigate the Critical Vulnerability" (giving no such timeline to remediation - 4.f.ii) or "Document that the factual basis for the CA's determination that the vulnerability does not require remediation" (with the only requirement being documentation, and no consideration whatsoever if the factual basis was wrong or the CA's determination was incorrect - 4.f.iii).</div><div><br></div><div>These are such significant "get out of responsibility free" cards that it does not seem to justify increasing the barrier to patching. Recall that, in the absence of something being deemed a Critical Vulnerability, CAs are afforded six months to either patch, or determine that they don't want to patch (1.l).</div><div><br></div><div>Thus, it seems the definition is perhaps the least important of the things to change, given the structural security issues with the NCSSRs of the lack of transparency and accountability required of CAs in keeping their systems secure. However, if it's urgent to correct this editorial issue, rather than the underlying security issues, it seems best to ensure this change is merely editorial in nature, by continuing to define those events that are critical --for CAs-- as those that are 7.0 or higher. We know that CVSS scores provide a baseline metric, but that specific environments and use cases can either mitigate (as the NCSSRs seem to give significant deference to) or amplify (as we know from CA incidents in the past) those scores. As such, it doesn't seem necessary or desirable to further relax requirements on CAs' need to maintain a secure-by-default posture.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 9, 2020 at 5:44 AM Neil Dunbar via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This begins the discussion period for Ballot SC39: Definition of <br>
Critical Vulnerability<br>
<br>
<br>
The following motion has been proposed by Neil Dunbar of TrustCor and <br>
endorsed by Ben Wilson (Mozilla) and Corey Bonnel (DigiCert).<br>
<br>
The NetSec discussion document for this ballot is attached to this email.<br>
<br>
Purpose of Ballot:<br>
<br>
It was brought to the attention of the NetSec Subgroup that the URL in <br>
the NCSSRs which points to the definitions of the CVSS security scoring <br>
system is no longer the appropriate one; moreover the definition of <br>
“Critical Vulnerability” is no longer strictly correct by the <br>
definitions currently posted by NIST.<br>
<br>
Definitions of terms should always be consistent, especially when the <br>
term is canonically defined by an external body; references should be <br>
updated as and when they change on the canonical source.<br>
<br>
-- MOTION BEGINS --<br>
<br>
This ballot modifies the “Network and Certificate System Security <br>
Requirements” based on Version 1.5.<br>
<br>
Under the section “Definitions”:<br>
<br>
Remove the current definition:<br>
<br>
Critical Vulnerability: A system vulnerability that has a CVSS score of <br>
7.0 or higher according to the NVD or an equivalent to such CVSS rating <br>
(see <a href="http://nvd.nist.gov/home.cfm" rel="noreferrer" target="_blank">http://nvd.nist.gov/home.cfm</a>), or as otherwise designated as a <br>
Critical Vulnerability by the CA or the CA/Browser Forum.<br>
Insert a new definition:<br>
<br>
Critical Vulnerability: A system vulnerability that has a CVSS v3.0 <br>
score of 9.0 or higher according to the NVD or an equivalent to such <br>
CVSS rating (see <a href="https://nvd.nist.gov/vuln-metrics/cvss" rel="noreferrer" target="_blank">https://nvd.nist.gov/vuln-metrics/cvss</a>), or as <br>
otherwise designated as a Critical Vulnerability by the CA or the <br>
CA/Browser Forum.<br>
<br>
-- MOTION ENDS --<br>
<br>
* WARNING *: USE AT YOUR OWN RISK. THE REDLINE BELOW IS NOT THE OFFICIAL <br>
VERSION OF THE CHANGES (CABF Bylaws, Section 2.4(a)):<br>
<br>
A comparison of the changes can be found at:<br>
<br>
<a href="https://github.com/cabforum/servercert/compare/8f63128...neildunbar:54c201f" rel="noreferrer" target="_blank">https://github.com/cabforum/servercert/compare/8f63128...neildunbar:54c201f</a><br>
<br>
This ballot proposes one Final Maintenance Guideline.<br>
<br>
The procedure for approval of this ballot is as follows:<br>
<br>
Discussion:  (7+ days)<br>
Start Time: 2020-12-09 17:00 UTC<br>
End Time:  not before 2020-12-16 17:00 UTC<br>
<br>
Vote for approval    (7 days)<br>
Start Time: TBD<br>
End Time: TBD<br>
<br>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote></div></div>