CVE ID Syntax Change and Options

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

All,

 

As discussed in the Editorial Board teleconference on October 31, it

is time to update the CVE ID syntax so that CVE can support more than

10,000 identifiers in a single year (the "CVE-10K Problem").

 

Some discussion was held on the Editorial Board list back in 2007, but

no official decision was reached or implemented (see

http://cve.mitre.org/data/board/archives/2007-01/threads.html).

 

However, it is now time to resolve this issue.  It sometimes causes

distractions in the larger Global Vulnerability Reporting (GVR)

discussions, and it is possible that MITRE could generate more than

10,000 identifiers in 2013 due to additional staff and recent

process/infrastructure improvements.

 

It will take many consumers 6 months or more to fully adopt any new

syntax, so sufficient warning is required, and we will need to develop

a transition plan for the new syntax.  We will iron out the details

later.

 

Below are several options for ID syntaxes.  Please respond to the list

with your opinions about:

 

* suggestions for a different syntax?

 

* which syntax would be best for consumers?

 

* which syntax would be easiest/cheapest to adopt?

 

We are not holding any formal vote at this time.

 

 

Considerations for a Good Syntax

--------------------------------

 

For a new CVE ID syntax to be "good," it should have most (or all) of

the following properties:

 

1) Large ID space, i.e., a large number of potential IDs that could be

   assigned.

 

2) Usability by consumers - such as the ability to recognize that the

   ID is a CVE number, and to reduce confusion.

 

3) Ease of adoption by consumers.

 

4) Low maintenance/adoption costs for both consumers and providers.

   For example, some ID schemes could reduce memory/disk overhead, or

   it could be easy to extend regular expressions that are currently

   used to detect or manage CVD IDs.

 

5) Delayed impact of the syntax change - since any change will have

   many unexpected effects on downstream consumers, we want to give

   people as much time to adjust to the new syntax as possible.  So,

   it may be favorable to use a syntax that doesn't appear to change

   until 10,000 identifiers are needed.

 

6) Syntax version recognition - if possible, it should be clear to the

   consumer or an automated system as to which syntax version is being

   used for an ID - the old syntax, or the new syntax.  For example,

   ISBN numbers were originally 10 digits long, then    expanded to 13

   digits - so the length of the ISBN clarifies which version is being

   used.

 

7) Future-proofing - if possible, the ID scheme could be flexible

   enough that future requirements do not force additional changes.

 

 

 

Option 1: Year + arbitrary digits, no leading 0's

-------------------------------------------------

 

Examples: CVE-2013-1234, CVE-2013-12345 (if 4 digits or less, leading

0's would be used, e.g. CVE-2013-0056 instead of CVE-2013-56)

 

Impact: delayed until MITRE produces 10K IDs in a year

 

Number of IDs: 1,000,000 per year (assuming 6 digits)

 

Note: alphabetic sorting would not list CVE-2013-9999 and

CVE-2013--10000 next to each other.

 

 

 

Option 2: Year + 5 digits, leading 0's

--------------------------------------

 

Examples: CVE-2013-01234, CVE-2013-56789

 

Impact: immediate upon adoption (many existing parsers might

misinterpret "CVE-2013-01234" as "CVE-2013-0123" by assuming only 4

digits).

 

Number of IDs: 100,000 per year

 

Notes: this might not have extensive impact for some adopters,

e.g. some liberal regular expressions such as (CVE-\d+-\d+) would work

for both old and new syntax.

 

 

 

Option 3: Year + 6 digits, leading 0's

--------------------------------------

 

Example: CVE-2013-012345, CVE-2013-678901

 

Impact: immediate upon adoption (many existing parsers might

misinterpret "CVE-2013-012345" as "CVE-2013-0123" by assuming only 4

digits).

 

Number of IDs: 1,000,000 per year

 

Notes: this might not have extensive impact for some adopters.  For

example, some liberal regular expressions such as (CVE-\d+-\d+) would

work for both old and new syntax.

 

 

 

Option 4: Non-standard year + 4 digits

--------------------------------------

 

Example: CVE-1013-1234, CVE-3013-1234 (instead of using the current

year, a year before 1999 or after 3000 could be used once 10,000 is

reached in a single year)

 

Impact: delayed

 

Number of IDs: 100,000,000 overall

 

Notes: could cause user confusion (strange-looking IDs that are

assumed to be typos), but might have reduced adoption costs (many

current regular expressions would still work, ID is the same length as

the original syntax).

 

 

 

Option 5: year + 4 hex digits

-----------------------------

 

Example: CVE-2013-A9E4

 

Impact: delayed

 

Number of IDs: 65,535 per year

 

Notes: could cause user confusion (strange-looking IDs that are

assumed to be typos), but might have reduced adoption costs (length is

the same), although it would break regular expressions that assume

only digits.

 

 

 

Option 6: year + 4 alphanumeric

-------------------------------

 

Example: CVE-2013-ZW1K

 

Impact: delayed

 

Number of IDs: 1.7 million per year

 

Notes: could cause user confusion (strange-looking IDs that are

assumed to be typos), but might have reduced adoption costs (length is

the same), although it would break regular expressions that assume

only digits.

 

 

 

Option 7: CCE-Style (year + arbitrary digits + check digit)

-----------------------------------------------------------

 

Example: CVE-2013-12345-6 (the "6" is a check digit, following the

Luhn Check Digit Algorithm)

 

Impact: immediate

 

Number of IDs: Effectively unlimited

 

Notes: the check digit provides an easy way to automatically spot

typos in IDs, which happens in CVE multiple times per year (for

example, sometimes vendors release advisories with typos in the CVE

IDs).  The number of digits between the year and the check digit is

effectively unlimited, since the boundaries are marked by hyphens.

There may be user confusion, and people might leave out the check

digit entirely.

 

 

 

Option 8: CERT-VU/JVN Style

---------------------------

 

Example: CVE#12345678

 

Impact: immediate

 

Number of IDs: 100,000,000 overall

 

Notes: this ID does not encode the year, which many consumers like,

since it is an approximation of when the issue became public.