CVE ID语法变化——投票选举(截止日期4月14日11:59 EDT)

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
投票选举
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

第一选择:选择C


原因(首选):
我们觉得选项C是整体的最佳技术解决方案的问题。它最小化转录错误的可能性,以及消除了长串的前导零。

我们喜欢的组合没有前导零分心,以及有校验位,以确保你有一个完整的ID。校验数位的缺点是增加了复杂性在人类式的搜索。我们认为大多数工具可以解决这个通过允许搜索部分cf。这将允许人类用户离开时的校验位搜索,而且还拉起的脆弱性。校验位的主要目的是为出版商的漏洞,确保引用他们的弱点使用正确的ID。这也将是有用的工具,产生某种类型的报告,可以肯定的是,他们已经准确地识别漏洞报告。

校验位的性质,我们建议Verhoeff或达姆算法,而不是Luhn算法。两种算法可以检测比Luhn互换算法。Luhn算法的唯一的优势是它更容易hand-calculable。我们不觉得任何人将这些手工计算,所以Luhn算法不如在所有方面。

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

第二个选择:选择一个


原因(第二选择):
我们认为这是最人性化的格式。
它优于选项B,长度是明确的,你知道你有一个完整的CVE-ID与否。可以肯定的是它没有在邮件或者被截断。的明显的缺点,无法处理1000000漏洞在一年内,我们觉得这是不太可能发生,因此,不是一个重要的限制。如果有一些需要目录1000000漏洞在一年,当前CVE方案将不足以任务,和其他可能会取而代之。

我们率这背后选项C的原因是,我们觉得需要提供大量的前导零对许多漏洞会导致转录错误和含糊之处。你会如何解释cve - 2014 - 00007,例如?是完全无效的吗?它是cve - 2014 - 000007,我们错失了一个“填充零”,还是打算cve - 2014 - 00007 - x,和最后一个数字被截断?

从用户搜索的角度来看,如果选项被选中,我们将鼓励工具使前导零可选在搜索。换句话说,如果一个用户搜索cve - 2014 - 7,搜索结果应该包括cve - 2014 - 000007(可选地,以及cve - 2014 - 00007 - X, cve - 2014 - 0007 - xx,等X代表任何数字0 - 9)。但用户搜索很多漏洞会厌倦了输入和计算前导零,这就是为什么我们支持被允许省略搜索。这也是为什么我们支持选项C,它没有前导零。
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

最后的选择:选择B


原因(最后的选择):
我们觉得完全开放式的性质选择B开辟了太多错误的空间。选项C是一个更好的方法来提供开放式的脆弱性数字。太很难告诉你是否有输入错误CVE-ID使用选项B,我们不觉得需要编目> 999999漏洞在一年内都可能选项B没有真正的优势,相比其他两个选择。