[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Proposal: CVE candidate/approved numbering scheme


All:

Based on all the emails that were generated discussing the candidate
numbering plus my review of other fields, I've come up with an
approach that's fairly similar to Russ' last email.  Let us know what
you think!

- Steve


Summary
-------

- candidate numbers should be public

- to avoid multiple naming schemes, candidate numbers are the same as
CVE numbers, except they are prefaced by CAN- instead of CVE-

- a Candidate Numbering Authority (CNA) is given the privilege to
assign candidate numbers (e.g. editorial board members or established
OS/application vendors)

- candidates are not put in the CVE until they are approved

- candidate status/etc. is kept in CMEX

- candidate numbers are automatically generated and accessed via a
restricted web interface (ultimately)



Details
-------

Candidate numbers should be public and should be assignable on
proposal, not after vetting, to allow tracking of early information
and advisory numbering.  But we don't want 2 separate naming schemes,
because the candidate number could become a de facto standard instead
of a CVE number.  So the candidate numbers must be as similar as
possible to the CVE numbers, if not exactly the same.  Numbers should
also be simple for (relatively) easy human readability.

BUT - we want to have a "stable" way of assigning candidate numbers,
some rough guarantee that a candidate number will likely have a
one-to-one relationship with the approved CVE vulnerability.  Each
candidate number should have a good chance of being the same as a CVE
number.

We define a Candidate Number Authority (CNA), who has the capability
to reserve a candidate number.  There are more CNA's than editorial
board members.  E.g., established application/OS vendors would be
CNA's, but they probably wouldn't be editorial board members.  We can
name an entity a CNA if they're accepted by a percentage of editorial
board members; they must show continued accuracy or effectiveness in
proposing candidates that are later accepted.

Any member of the editorial board is automatically a CNA.  We can
extend CNA privileges to other entities after CVE public release.

Only a CNA can assign candidate numbers.  This approach forces
"casual" vulnerability announcers to go through a CNA (e.g. *Bugtraq)
to get a real number.  It's possible that an entity will decide to act
solely as a CNA, filtering information coming from non-CNA entities.
CNA's will present the candidate name/status in a standardized way,
and will encourage others to do so.

CNA's assign a candidate number, *but* (a) follow established content
decisions to determine appropriate level of abstraction, etc.; (b)
attach a "pending status" to the candidate number; and (c) state that
the number is a candidate ONLY, include a link/reference to MITRE CVE,
and update all information sources if/when the candidate is approved.

MITRE gives CNA's the ability to reserve a number (or block of
numbers, e.g. for *Bugtraq) through limited web site access or another
mechanism.

Each candidate has 5 CMEX fields associated with it:
  - name
  - creation date
  - id/name of the CNA who proposed it
  - status
  - status explanation (formatted text)

The name is an encoding of a year and a unique number N for the Nth
candidate proposed that year, prefaced by CAN-.  Including the year
limits how big N would need to be, improving memorability.  Example:

   CAN-1999-0001

(The assumption is that no more than 10,000 candidates would be
proposed per year.  I think it's dangerous to assume we won't reach
1000 on occasion.)

Any CNA can obtain and announce a candidate name.  When a candidate is
first proposed, its status is PENDING.  The CNA obtains the name from
MITRE, perhaps through an automatic "name reservation" system.

The candidate is added to CMEX.  The candidate is *NOT* put in the CVE
itself.  Anybody searching the CVE will *not* find the candidate
number.  This, in combination with the CAN- prefix, reinforces the
notion of the number as "unofficial."  A separate interface (e.g. a
different web page) is provided to allow a person to review a
candidate's status.


After a candidate has been reviewed, its status becomes one of:

- APPROVED.  Candidate has a 1-to-1 relationship with the approved CVE
entry, and is assigned the name of CVE-1999-0001, i.e. the CAN prefix
is replaced by CVE.  The candidate is added to the CVE.  References to
the CAN- number (e.g. in advisories) should be modified to reflect the
CVE number, where possible.

- MODIFIED.  The candidate has been substantially modified during
review (e.g. it is split or merged).  It retains the CAN- name.  The
status explanation identifies the nature of the modification
(e.g. SPLIT into CVE-1999-0012 and CVE-1999-0013).  This candidate
number is NOT APPROVED and is not included in the CVE; however, other
candidates may be added to the CVE as a result, and this should be
reflected in the status explanation.  References to the CAN- number
(e.g. in advisories) should be modified to reflect the CVE number,
where possible.

- DENIED.  The candidate is not a CVE vulnerability, or it is a
duplicate, or subsumes/is subsumed by other vulnerabilities.  Status
explanation identifies the reason for denial.

CVE vulnerabilities that result from APPROVED or MODIFIED candidates
include back-pointers (i.e. references) to the candidate number(s).

Each CNA should prevent MODIFIED or DENIED status as much as possible,
by closely following content decision guidelines.  In cases where
content guidelines are not clear, CNA's should get advice from the
editorial board.  CNA's that continually produce MODIFIED or DENIED
candidates may not retain status of CNA, because they are "muddying
the waters" and diluting the effectiveness of the naming.


At a later date, an approved CVE vulnerability may become:

- OBSOLETE.  Content decisions are changed, errors are fixed, etc.
Status explanation identifies the reason for obsolescence, and may use
either the MODIFIED language (split/merge) or DENIED language
(not-a-vulnerability, etc.)  The vulnerability remains in the CVE.
Page Last Updated or Reviewed: May 22, 2007