Candidate numbering scheme discussion - summary so far

["Steven M. Christey" <coley@linus.mitre.org>]

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.