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

所有：我综述了候选人编号方案讨论的摘要，并在下面包括。任何错误都是我的。在我看来，“正确的答案”并不太远。在第二天或两天，戴夫和我可能会根据到目前为止的讨论提出一些建议。作为我们的建议可能的指标 - 如果您与Russ的最后一封电子邮件有任何很大的分歧，最好现在说出来;-)-史蒂夫候选人编号计划/等。--------------------------------------对话流---------------------------------------  1）史蒂夫：候选号，can-id-date-num。好处：每个人都使用自己的数字，不需要中央编号系统2）亚当：同意，如果“ num”成为cve-num 3）史蒂夫：不能保证候选人将与CVE-NUM相同；另外，使用其他名称，可以更早地添加4）RUSS：有CAN-01-1999051501，然后是CVE-01-19999051401。好处：不依赖中央编号系统，人们可以内部分配，与CVE的联系很明确。5）戴夫：是的，是对拉斯的，但这不是很难忘6）史蒂夫：鲁斯的方法的问题，如果候选人的数字被公开 - 滥用ID，缺乏难忘，不是候选人数字之间的1比1的关系 and CVE numbers. 7) Bill: agrees with Steve - minimalism in CVE, all previously proposed naming schemes were ultimately rejected; include candidate number in references 8) Adam: agree with Dave - shorter numbers are more usable, include with references 9) Elias: never allow candidate numbers to be outside the working group. Vendors should get a proper CVE number for advisories, or wait. Candidates should be in CMEX (assuming CMEX is private). But candidate numbers would show up in the list archives. 10) Steve: can't get around candidates being in list archives. Public candidate numbers help tracking of early information and allowing vendors to assign their own numbers. An alternate approach would be to provide a "conditional" assignment of a new CVE number. But risk of multiple numbering schemes. 11) Elias: use of candidate names in *Bugtraq will preclude the use of CVE numbers; candidates will continue to be used. 12) Andre: agrees with Elias. Also introduces overhead in cross referencing. Alternatives: submit new vuln's to cve-review group, but introduces some delay. Or, submit new vuln's to an automatic CVE number generator - but has gaps in CVE indexing. 13) Craig: shorter numbering scheme is more readable. 14) Craig: should a candidate number be accessible to the public? 15) Craig: agrees with Andre's approach for submitting new vuln's to cve-review group to get numbers. 16) Craig: a candidate numbering scheme is required. But if public, problems with use of candidate name. Discussions on vuln's before CVE assignment would be "lost" 17) Gene: use candidate numbers like temp-99-01. "temp" makes it clear that the number is temporary. 18) Steve: Gene's idea would require central number assignment, could cause problems if available to everybody. Temp- name could *still* become commonly used. 19) Gene: central number assignment could be automated and limited only to authorized people. We should try an approach like he suggested - stop debating and experiment! 20) Craig: likes the "temp-" in front of a CVE number. What about vuln's discovered by non-participants? 21) Steve: only assign numbers from "authorized" participants; want to ensure quality of information brought into the input forum, don't want to duplicate *Bugtraq. 22) Russ: Want to convince the vendors (security products and app/OS vendors) to utilize CVE in their product information. Need to get numbering right the first time because vendors may have committed their products to it. So we can't "weaken" the use of CVE number, which an alternate numbering scheme would do; make it the same as, or similar to, the official number. Candidacy discussions should be fully viewable, so assume that candidate numbers effectively will be public. Either just use email Subject lines for id'ing a candidate, or have MITRE create a CVE "surrogate" number, some portion of which turns it into an accepted number. Need to record all candidate numbers in CMEX. Vendors will go public with information before official assignment in a CVE number, so you want to encourage it as much as possible. The number must be assignable on discovery, not on decision. Somehow encode status within the name. Vendors using a candidate CVE number should keep their references up to date. Ref's to candidate numbers should link to MITRE. MITRE should have a list of pending and accepted numbers. There will be gaps in the CVE numbers, but that's OK.