[TECH] Numbering Schemes for Legacy Candidates
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
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
Details are below.
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
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
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.