Re: CVE ID Syntax Change - Voting Ballot (Deadline April 14, 11:59 PM EDT)

[Carsten Eiram <che@riskbasedsecurity.com>]

Voting on behalf of Risk Based Security (RBS).

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

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



FIRST CHOICE:

OPTION A: Year + 6 digits, with leading 0's

  Examples: CVE-2014-000001, CVE-2014-000999, CVE-2014-001234,
  CVE-2014-009999, CVE-2014-010000, CVE-2014-054321, CVE-2014-099999,
  CVE-2014-100000, CVE-2014-123456, CVE-2014-999999

 

REASONS (first choice): 

Most straight-forward, closely resembles the existing scheme, fixed-length (i.e. possible to recognize bad (truncated or the opposite) values, and should be perfectly future-proof.

Elaborating on the latter claim, which I know there is disagreement over. There are two ways we may exhaust 6 digits:

1) A purely theoretical explosion in vulnerability reports and coverage (keeping in mind that MITRE currently has trouble keeping up with the existing trend and don't guarantee all vulnerabilities will be assigned CVEs). A change from 8K-10K vulnerabilities reported per year to > 1 million is simply unrealistic. Even if someone starts auditing a ton of projects with automated code scanning tools and without any manual follow-up analysis just dumps the results on some mailing list, we would be hard-pressed to exhaust 6 digits. We would be discussing resource problems long before hitting those numbers, as neither CVE nor any CVE processors will be able to keep up with such a load.

2) Some relevant arguments were made w.r.t. taking into account possible future changes to CVE assignment rules / policies / coverage and the number of CNAs on a global scale. While good points, 1 million CVEs per year should nicely cover additional assignments as well as a likely increase in CVE waste (i.e. eternally reserved/unused entries and duplicate assignments) as the result of more and larger CNA pools. We can assign 100K CVE identifiers per continent and still have plenty to spare.

It seems to me that most arguments against this choice center around wanting to play it safe. I have not seen a single convincing argument that 2 extra digits won't be sufficient. There are perfectly valid reasons for preferring other choices, but not liking this specific choice simply because we're afraid of making a mistake and eventually exhausting 6 digits without being able to put some concrete numbers or similar on the table is pretty poor. We should make a sound decision based on facts, our long experience in this industry, and knowledge of the trends - not just random fears without concrete information. Naturally, we don't want to run out again, but we are going from 10K to 1 million; currently, we're hard pressed to even make it into the 5 digits.

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

SECOND CHOICE:

OPTION B: Year + arbitrary digits, no leading 0's except IDs 1 to 999

  Examples: CVE-2014-0001, CVE-2014-0999, CVE-2014-1234,
  CVE-2014-9999, CVE-2014-10000, CVE-2014-54321, CVE-2014-99999,
  CVE-2014-100000, CVE-2014-123456, CVE-2014-999999, CVE-2014-1234567

 

REASONS (second choice):

Somewhat resembles the existing scheme, but as Ken Williams of CA also covers, it's just a fail waiting to happen w.r.t. truncation problems. If this scheme should have been somewhat useful, it should have been Option A with the possibility of adding extra digits. In that case, it would at least very unlikely open up for truncation problems. It's also messy - or "ugly" as Brian Martin colorfully points out.

 

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

LAST CHOICE:

OPTION C: Year + arbitrary digits + check digit

  Examples: CVE-2014-1-8, CVE-2014-999-3, CVE-2014-1234-3,
  CVE-2014-9999-3, CVE-2014-10000-8, CVE-2014-54321-5,
  CVE-2014-123456-5, CVE-2014-999999-5, CVE-2014-1234567-4

 

REASONS (last choice):

Honestly, a messy and pointless scheme that will never or extremely rarely be fully utilized so what is the point? I see this as purely academical and very impractical.