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

[TECH] Numbering Schemes for Legacy Candidates

All,

MITRE expects to be proposing legacy candidates to the Board within a
month or two.  However, as Board members discovered during an
unexpectedly lengthy discussion at the face-to-face meeting, there are
various ways that we could choose to number those legacy candidates.
Each has strengths and weaknesses.

Legacy candidates cannot be proposed until we've decided how they
should be numbered.

The meeting summary, included below, proposes 3 options:

1) Assignment-based encoding (i.e. the current approach) - use the
   year that the number was assigned, e.g. CAN-2001-XXXX

2) Publication-based encoding - use the year that the issue was first
   disclosed to the public, e.g. CAN-1997-XXXX

3) Hybrid encoding - use 1999-XXXX for all 1999 issues and earlier,
   and use publication-based encoding for later years.

There may be other options.  Slight variations are identified in the
summary.

While discussing this, we should account for:

1) Maintenance costs for CVE-compatible products/vendors

2) Possible confusion/misunderstanding by CVE users

3) Impact on CVE candidates and entries that already have numbers
   assigned to them


While discussing this, we should also remain open to the idea of
switching to an entirely different numbering scheme for candidates and
entries, as discussed at the meeting.  It will be easier to switch
schemes sooner rather than later.  (See "Rethinking the CVE naming
scheme" in the summary at
http://cve.mitre.org/board/archives/2001-03/msg00014.html)

Details are below.

- Steve



Numbering Scheme For Legacy Candidates
--------------------------------------

The current approach for numbering candidates is CAN-YYYY-NNNN, where
YYYY is the year in which the candidate number is assigned - *not* the
year in which the vulnerability is publicized.  (The same applies to
CVE entry names, in which the CAN- prefix is converted to CVE-, but
the rest of the identifier remains the same).

If applied to legacy candidates, the current approach would produce
many vulnerabilities that have CAN-2001-NNNN names, but were
publicized in 1999 and earlier.  Many people may have the perception
that the "year" slot in the CVE name is actually related to the year
in which the vulnerability is publicized.  In addition, there may be
an "aesthetic" desire to have the candidate name reflect the year of
publication, as a high-level means of managing vulnerability
information based on how old it is.

Regardless of the public's misconception of the meaning of the year in
the CVE name, many of the candidates/entries with 1999-NNNN names were
actually announced earlier than 1999.  For the most part, CVE items
with 2000-NNNN names were publicized in 2000, but some 2000-NNNN names
are for older issues.  Similarly, some problems discovered in November
and December 2000 have 2001-NNNN names.  So, many of the current
CVE/CAN names are already inconsistent with respect to the year of
publication for the associated vulnerabilities.

However, depending on the number of new vulnerabilities discovered
this year, and the number of legacy candidates that MITRE produces, it
is possible that more than 10,000 candidate names will need to be
assigned this year.  The name space only supports up to 9999 different
names per yer.  (This is being referred to as "the CAN-10K problem").
There are ways of extending the name space if necessary; for example,
by moving to a hexadecimal numbering scheme instead of decimal, 65536
different vulnerabilities could be assigned per year without changing
the number of characters in the name.  However, it is not known
whether such a change would adversely impact how some CVE-compatible
products may store the CVE names.

There are several factors that need to be considered when selecting a
naming scheme for legacy candidates:

  1) It was suggested that to help users manage CVE based on date of
     publication, that a separate field could be added which lists
     such a date.  However, this information is currently in other
     databases, and thus increases the risk of CVE's competition with
     those databases.  In addition, the date of publication would
     rarely help someone in mapping a specific vulnerability to a CVE
     name, although it is occasionally useful in discriminating
     between extremely similar vulnerabilities in the same product.
     The references and description, on the other hand, are essential
     for looking up the CVE name for a problem.

  2) If a naming scheme is adopted which encodes the year of
     publication in the name, then all the entries or candidates that
     currently exist should *NOT* be renamed just to make things
     consistent, since there is such a large number of
     CAN/CVE-1999-NNNN items that were not discovered in 1999.  The
     maintenance costs would be high for CVE users and compatible
     vendors.  Thus, even if the Board adopts a "publication-based"
     encoding, it will not apply to all CVE items.

  3) If a publication-based encoding is not used, then users will need
     to be able to distinguish between new candidates and legacy
     candidates.  This information could be provided in reports that
     are accessible on the CVE web site.

Following are the different approaches that were discussed by the
Board.

  1) Assignment-based encoding: continue to use the current approach,
     i.e. assign CAN-2001-NNNN (or CVE-2001-NNNN) to the issue, since
     2001 is the year in which the candidate is assigned.

     Pro: emphasizes that the encoding of the year in the CVE name is
     not related to the year of announcement.  Simplest to implement.

     Con: increases the possibility of misuse by consumers.  For
     example, consumers might focus on the last 200 CAN-2001-NNNN
     candidates, mistakenly believing that they are the most recent
     issues that have been discovered.

     Con: susceptible to the CAN-10K problem.

  2) Publication-based encoding: assign YYYY-NNNN, where YYYY is the
     year in which the issue was first publicized.

     Pro: more likely to address common public misconceptions.

     Pro: least susceptible to the CAN-10K problem.

     Pro: will be accurate for all issues that are publicized in 2002
     and later.

     Con: 1999-NNNN, and portions of 2000-NNNN and 2001-NNNN, will not
     be consistent with the approach.

     Con: some complications if a vulnerability is publicized one
     year, a candidate is created, and then it becomes clear that the
     problem was actually publicized in earlier years.

  3) Hybrid encoding.  If the problem was published in 1999 or
     earlier, use 1999-NNNN; otherwise, use the year of publication.

     Pro: emphasizes that the encoding of the year in the CVE name is
     not related to the year of publication, for any issues that were
     publicized in 1999 or earlier.

     Pro: For 2002 and later years - and all but the first 150
     candidates of 2001 - the year of publication will be encoded in
     the CVE name.

     Con: For 2000 and 2001, some candidate names will not include the
     year of publication.

     Con: most susceptible to the CAN-10K problem, because there may
     be more than 10,000 vulnerabilities from 1999 and earlier that
     ultimately require names.

To help end users better manage or discriminate between new and legacy
issues, and highlight the differences for purposes of user education,
it was suggested that legacy candidates be assigned names with the
highest sequence numbers available.  For example, one could start at
CAN-2001-9999, CAN-2001-9998, etc. for legacy candidates that are
created in 2001.  An alternate scheme was proposed in which legacy
issues could be assigned CAN-2001-5000 and advanced upward.  However,
it is possible that these significant gaps could cause confusion.  In
addition, some people may be using the highest-numbered candidate for
other purposes, which could have unexpected consequences.  For
example, it was noted that some people mirror individual CVE entries
and candidates on the CVE web site by requesting information up to 100
"sequence numbers" above the most recent candidate; such mirrors might
immediately attempt to download 10,000 candidates for 2001, instead of
the current number of about 250.

Regardless of which approach is adopted, users will need to be
educated about it.  It is likely that additional information will be
needed on the CVE site; in addition, CVE-compatible vendors will need
to address user misconceptions.

Also, MITRE will not be able to start proposing legacy candidates
until the numbering scheme is finalized.
Page Last Updated or Reviewed: May 22, 2007