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

Re: CVE ID Issuance Strategies Using the New ID Syntax

On 2013-06-18 14:36 , Steven M. Christey wrote:

> - whether we should avoid assignments of CVE-2014-0001 through
>   CVE-2014-0999 (avoiding any "leading zeroes")
...
> Besides the possible implementation costs for some parties, are there
> any other benefits to avoiding leading zeroes?

> - whether issuance should reduce the risks in which 5-digit IDs might
>   be inadvertently truncated to 4-digit IDs ("truncation mitigation")
...
> Even if our communication strategy is highly successful, there is
> still a risk that either (1) some developers will not learn about the
> ID syntax change, or (2) some developers will not be able to fix their
> code in time.  Based on some research we conducted earlier this year,
> we have seen a number of CVE-ID implementations in which 4 digits are
> assumed.  The 4-digit assumption might be most prominent in code that
> (1) extracts or parses CVE IDs, or (2) outputs CVEs assuming a
> specific format or length.

I'll speak up *mildly* in favor of both avoiding leading zeros and the
protecting block for the first batch of 5 digit IDs.  These actions
would support a stronger message about the syntax change, with the goal
being to get people moving sooner than later.  And even with the syntax
change and these two controls, there's still lots of lead time, CVE
users don't have to meet a Jan 1 2014 deadline.

MITRE ultimately controls issuing IDs, so it's easy to implement both
controls.

Anybody who can parse 4 digit IDs can keep on truckin' -- the only risk
is reaching the 5 digit mark a little sooner.

There will probably be some head scratching about why the numbers are
skipping around.

I'd suggest keeping the protecting block in place until the 5 digit mark
is reached.

The obvious counter argument (for leading zeros) is "Why fix something
that isn't broken?"


 - Art
Page Last Updated or Reviewed: October 03, 2014