RE: The CVE-10K Problem

["Peter Mell" <mell@nist.gov>]

The solution Mark is advocating appears the best to me and will be easy to
implement within the National Vulnerability Database.

Peter Mell

> -----Original Message-----
> From: owner-cve-editorial-board-list@LISTS.MITRE.ORG [mailto:owner-cve-
> editorial-board-list@LISTS.MITRE.ORG] On Behalf Of Mark J Cox
> Sent: Monday, January 15, 2007 10:03 AM
> To: Steven M. Christey
> Cc: cve-editorial-board-list@LISTS.MITRE.ORG
> Subject: Re: The CVE-10K Problem
> 
> I like seeing CVE identifiers used in publications that go to
> non-technical audiences, and I fear we'd frighten them away with hex.  I
> find the year useful, even if it's slightly out by one or two years for
> some issues.
> 
> I almost liked changing the initial identifier based on the type of issue
> (why not put all those vulnerable webapps into CVF-2007) but I think
> people would be confused because the CAN prefix mapped to CVE directly, so
> CVE-2004-2001 == CAN-2004-2001 but CVF-2007-0001 != CVE-2007-0001.
> 
> I'm pretty sure everyone implementing tools around CVE will have to make
> tool changes no matter what, so I'd much prefer us rolling over to
> CVE-2007-10000 which is a) what people will expect b) much less of a hack
> and c) gives the tools at least half a year to prepare.  I also prefer it
> since half the Red Hat tools will work just fine where we used the regexp
> C\S\S-\d+-\d+ for validity.
> 
> Red Hat itself moved from 3 digit to 4 digit advisory identifiers at the
> start of 2006 (we added several new products and we share identifiers
> between security and non-security updates).  In the end we didn't need the
> whole range in 2006, but because we started it at the start of the year we
> were able to add the leading 0 to help fix the sorting issues.
> 
> Mark