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

Re: CVE ID Syntax Change and Options

On 2012-11-05 19:47 , Christey, Steven M. wrote:

> 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").

> * suggestions for a different syntax?

None -- unless we are planning to address a significant increase (and
that can be handled by options #1 and 7, or unless we want to partition
the assignment space so that CNAs or some other distributed/federated
system can better track CVE assignment.

  CVE-YEAR-CNAID-000000 ?

I don't see concrete plans for either of these, and #1 and 7 can adapt
to cover both cases.  I prefer keeping CVE close to the current 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.

Overall, I'm not sure what the future space needs are.  In working on
finding vulnerabilities with automated tools (mostly fuzzing), we've
seen the need to be able to assign 10^5 or more IDs per year with the
potential for linear growth with the addition of more fuzzing machines.
 But, I don't foresee CVE assigning IDs to every individual crash
report.  If we do expect significant growth (which would mean
drastically changing the nature of a CVE entry, or greatly increasing
throughput and coverage), then we need to go with arbitrary scale,
options #1 or #7.

> 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.

Could encourage people to do nothing then scramble when -9845 is
published in March.

> 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.

I like this idea, but is it necessary?  Conflicts somewhat with #5.

I don't well understand the costs of changing software to account for
the new syntax, so consider that when weighing my feedback.  (That is, I
don't know how many vendors have how many products that require how many
lines of code to be changed.  CERT just has a couple scripts and web
pages to worry about.)

So, I'm somewhat biased to pick a syntax that favors functionality and
longevity over ease of implementation.  I'm not too worried about the
impact of immediate change.  That could be shortsighted.

What's easier?  A longer ID with only digits, or a 4 character
alpha-numeric ID?

If compatibility with the current syntax is important, then I like
option #1.  I don't think alpha sorting is that important.  Can't I sort
results by the Assigned date?

> 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)

Mildly in favor, good for backwards compatibility.

> Option 2: Year + 5 digits, leading 0's
> --------------------------------------
> 
> Examples: CVE-2013-01234, CVE-2013-56789

> Option 3: Year + 6 digits, leading 0's
> --------------------------------------
> 
> Example: CVE-2013-012345, CVE-2013-678901

Neutral.  Distinct from old syntax, prefer option #3 for space reasons.

> Option 4: Non-standard year + 4 digits
> --------------------------------------

Strongly against, keep the year meaningful.

> Option 5: year + 4 hex digits
> -----------------------------
> 
> Example: CVE-2013-A9E4

> Option 6: year + 4 alphanumeric
> -------------------------------
> 
> Example: CVE-2013-ZW1K

Neutral, prefer 6 over 5 since it has more space.

> 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)

Mildly in favor, check digit might be a bit of over-engineering,
effectively unlimited space.

Does it make sense to retro-fit so that until the 10K mark, the check
digit is optional and leading zeros are used?

> Option 8: CERT-VU/JVN Style
> ---------------------------
> 
> Example: CVE#12345678

Strongly against.  This is not necessary for CVE and too radical a
change.  A major design goal of this syntax was to not leak timing
information (like the year and sequential IDs) for pre-disclosure
vulnerability tracking.


 - Art
Page Last Updated or Reviewed: January 14, 2013