Re: The CVE-10K Problem

[Alfred Huger <alfred_huger@symantec.com>]

I would tend to agree, this work around is more palatable over here as well.

-al


On 1/16/07 7:55 AM, "Peter Mell" <mell@nist.gov> wrote:

> 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