再保险:建议:CVE候选人/批准编号方案

所以,我不舒服的结构我们投入竞选,我试图找到方法来简化它。我一直在试图有效地消除可以从系统的数字。在我看来,我们有两个类别的脆弱性,我们希望可以为数字;编辑部发表问题想讨论,和警告,出版商希望包括CVE咨询相关数量。只有第二个状态需要提前很多。这里的问题是,当号码吗?我不认为Aleph看到物品感兴趣bugtraq编号,但拉斯希望NTbugtraq数字。这种差异来自不同层次的节制和控制列表的内容;Aleph非常自由,俄国人更加保守。俄国人倾向于验证之前通过他们前进。 So, as a straw man, I'd like to propose that we replace the CAN system with the ability to enter something in the CVE as "PROPOSED." Any member of the board can assign an issue a CVE number, which is then assigned to that problem. The CVE will contain issues which are later found to be known, or otherwise modified or denied. The CVE will end up with more in it than if we let the vetting happen in the CAN state, but the numbers will be no less sparse, since we'll have to keep the concordance between candidates and approved numbers. (Perhaps we can avoid locking by having each board member have a small group of numbers which they "hold" and can assign at will. Those members who publish a lot can hold a larger group, or anyone can say "I'm going to need a dozen over the next week, can I take 6412-6425?") This proposal offers simplicity in that we only have one type of numbers, CVE, rather than two, CAN and CVE. It offers more simplicity in that we do not define a stage of candidate numbering, and entities with that privledge. Adam On Thu, May 20, 1999 at 01:13:27PM -0400, Steven M. Christey wrote: | | Elias said: | | >Just exactly why would you need CAN-numbers in bulk? The most | >vulnerabilities I've ever seens any one organization publish in | >a single day has been three or four. | | I agree with Russ that a new CNA might need a number of candidates all | at once. There are also some potentially high-volume CNA's - for | example, the *Bugtraq moderators may want to follow up emails to the | lists with a candidate number, or provide one for the poster to | include in their email. (Just a suggestion, I know there might not be | a particularly efficient way to do this, and it adds to the workload.) | | But I think we should encourage CNA's to only reserve the number of | candidates they plan on using within, say, the next week or so. | Otherwise we'll introduce additional overhead by having to track a | larger number of inactive but pending candidates, as well as | increasing the risk of filling the candidate name space (i.e. 9,999 | per year) due to "hoarding." Some of that problem could be handled by | "expiring" unused candidates after a particular amount of time, but | that approach seems aesthetically unpleasant to me. | | - Steve