[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Candidate numbering scheme discussion - summary so far
All: I made up a summary of the candidate numbering scheme discussion and included it below. Any errors are mine. It seems to me that the "right answer" isn't too far away. In the next day or two, Dave and I will probably propose something based on the discussions so far. As an indicator of what our proposal might look like - if you had any big disagreements with Russ' last email, better speak up now ;-) - Steve Candidate Numbering Schemes/Etc. -------------------------------- Conversation flow ----------------- 1) Steve: Candidate numbers, CAN-ID-date-num. Benefits: everyone uses own numbers, don't need central numbering system 2) Adam: agrees, if "num" becomes CVE-num 3) Steve: can't guarantee that candidate will be same as CVE-num; also, use a different name, CAN-date-ID-num 4) Russ: have CAN-01-1999051501 then CVE-01-1999051401. Benefits: no reliance on central numbering system, people can assign internally, linkage to CVE is clear. 5) Dave: yes to Russ, but it's not very memorable 6) Steve: problems with Russ' approach, if candidate numbers are made public - abuse of ID's, lack of being memorable, not a 1-to-1 relationship between candidate numbers 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.