回复：候选人编号方案讨论 - 到目前为止的摘要

亚当·肖斯塔克（Adam Shostack）说：>在我看来，我们有两个类别的脆弱性，我们想要数字。编辑委员会想要>讨论的发表问题，并咨询出版商希望在咨询中包括CVE>相关号码的问题[在董事会审查之前]。>实际上只有第二个状态需要提早数字。我认为这是一个公平的评估。这也意味着在咨询中可能存在相对较少的候选数字。我怀疑总的来说，没有太多候选人会完全公开。是的，有人阅读EB（编辑委员会）讨论的档案将看到候选人号码，但是对这些讨论感兴趣的任何人都应该知道CVE数字与候选人之间的区别（或告知差异）。>因此，作为一个稻草人，我想建议我们将CAN System>替换为在CVE中输入“建议”的能力。董事会的任何>成员都可以将问题分配给CVE号，然后将其分配给该问题。CVE将包含以后>已知或其他修改或拒绝的问题。 I think the CAN system helps to reinforce the fact that a vulnerability hasn't been fully discussed in the CVE context. In my opinion, a CVE number should only be assigned to a well-understood vulnerability. The CVE "label" should imply stable information. Candidates by their nature will be largely unstable. So assigning a CVE number to a candidate "dilutes" the power of the CVE name, to use Russ' terminology. Also, under Adam's proposal, only board members would be able to assign CVE numbers. This would remove (or limit) OS/application vendors such as Microsoft, Sun, NetBSD, etc. from getting their own numbers - or it would force them to share sensitive data with a board member. If we allow the OS/application vendors to assign their own CVE number, we run a further risk of diluting the quality of the CVE number - because they might not understand content decisions as well as board members, and make a mistake which forces the CVE number to be unaccepted, split or merged, etc. I think we want to reduce split/merge and other content operations as much as possible, *especially* for CVE numbers. Another risk with having "proposed" CVE numbers instead of candidates - what happens when someone else refers to that CVE number but doesn't say it's "proposed"? It's inherently given more "stability" than is warranted. I think we should stay with the CAN approach. And even if it doesn't work as expected, I believe it would be easier for us to go from the CAN approach to something like Adam suggested, than to do it the other way around. Comments? - Steve