MITRE vote for CVE ID syntax

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

Here is MITRE's vote.

- Steve


=====================================================
VOTING BALLOT
=====================================================

Enter your votes as specified in the preceding "Instructions" and
"Filling out the ballot" sections.

*****************************************************

FIRST CHOICE: Option B


REASONS (first choice):

A substantial majority of the MITRE CVE team preferred Option B.  Its
strengths include:

- It can be expanded to cover any number of vulnerabilities in a year;
   it is infinite and will not need to be changed again.

- Compared to Option A, it is less likely that people will produce
   malformed IDs (due to factors such as transcription errors or
   omission of leading-0 digits).  This will make it easier to use
   non-CVE-speaking search engines such as Google to reliably find most
   public information about a given CVE.

- The IDs are more human-readable compared to Option A.  At least for
   the foreseeable future, most new-syntax CVE IDs will use only 4 or 5
   digits.

- This option will buy extra time for organizations to adopt the new
   syntax with extra digits, since the first 9,999 vulnerabilities of
   2014 will look just like original-syntax CVE IDs, so changes will
   not have to be implemented immediately in the January 2014 time
   frame.

One limitation is that users who are unaware of the syntax change
might assume only 4 digits and inadvertently truncate longer IDs; for
example, CVE-2014-12345 might be interpreted as CVE-2014-1234 by an
automated process that still assumes 4 digits in the ID.  Since both
IDs are acceptable in Option B, this could cause erroneous
communications about the wrong vulnerability.  There are also slightly
more complex rules to validate a CVE using this syntax.  Overall,
however, the benefits outweigh the costs.



*****************************************************

SECOND CHOICE: Option A


REASONS (second choice):

A small minority of the MITRE CVE team preferred Option A, primarily
because of the fixed ID length; validation of Option B syntax would
have more complex "rules" due to the requirements for leading 0's for
numbers between 1 and 999.

However, some of the most important limitations included:

- The large number of digits reduces the readability of the CVE ID.

- Compared to Option B, there is a higher likelihood that CVE
   publishers and users might omit some of the extra digits, producing
   malformed IDs that would make the CVE more difficult to find using
   search engines such as Google.

- We do not anticipate a time in the coming years, maybe even decades,
   when CVE would need to cover so many vulnerabilities in a year that
   8 digits (or maybe even 6 digits) would be necessary.