Re: CVE ID syntax down-select complete - Public Feedback to begin

[<Kent_Landfield@McAfee.com>]

Glad to hear there is a targeted list. Any chance you could make that MITE-Only listeners and Board Members that request opt-in? The decision is important and the more raw opinions the better from my perspective.  Yes, I know what I would be getting myself into… Others may not be interested…

As for the press, I feel the sooner we get this in the press the better for all.  The press loves follow ups as it give them something to write about that they don't have to think up themselves. ;-) This really is an on-going story anyway and it could be useful in getting the attention of the public early instead of just deciding and telling industry.  If we want an accepted outcome that people start reacting to quickly, we need to start the buzz sooner rather than later. It gets on people's radar and more importantly, on product/project roadmaps so the modifications can be done, tested and field in time. 

Thanks.

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: <Christey>, "Steven M." <coley@mitre.org>
Date: Friday, January 18, 2013 1:45 PM
To: Kent Landfield <Kent_Landfield@McAfee.com>, Common Vulnerabilities & Exposures <cve@mitre.org>
Cc: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: RE: CVE ID syntax down-select complete - Public Feedback to begin

Kent,

 

We created the cve-id-change@mitre.org alias, which has MITRE-only listeners.  We planned to summarize the inputs to the public and certainly could do it for the Board.  Moderating and managing too much active discussion could be very labor-intensive, though.

 

We are still finalizing which lists to post to, and I will post here once we’ve finalized.  We would also monitor those lists for any discussion as well.  This will likely include at least Bugtraq and oss-security.  Since these lists are publicly archived in multiple locations (hmmmm, maybe that’s an argument for Full-Disclosure too…).  These well-known lists are more likely to be remembered and easy to access in the future than any archives that we would maintain ourselves.  You make a good point about discussions spawning off and becoming difficult to track, but we could cover that in the various summaries and provide explicit pointers where necessary.

 

It doesn’t seem important to make a big press deal that the down-select has occurred, although it seems likely that there will be some attention.  It seems it would be more effective to wait for a press push until the final selection is made.  If we do too much press too soon, there will probably be less press interest when the selection occurs – and that’s the most important message we need to get out to the public.

 

- Steve

 

 

 

 

 

From: Kent_Landfield@McAfee.com [mailto:Kent_Landfield@McAfee.com]
Sent: Friday, January 18, 2013 2:07 PM
To: Christey, Steven M.; Common Vulnerabilities & Exposures
Cc: cve-editorial-board-list
Subject: Re: CVE ID syntax down-select complete - Public Feedback to begin

 

Steve,

 

Can you please let the Board know where you are posting this message so that we too can monitor the discussions ?   

 

How do you want to have real feedback?  Just list discussions ?  Feed the comments to a focused mailing list where selection preference can be indicated?  Only at RSA's public event? (Last one I know is wrong. ;-))

 

It might be good to set up a temporary mailing list just for taking comments that individuals and companies want the Board to hear.  Preferably not the Board list. ;-) And you probably do not want it going to cve@mitre.org… ;-)  But I do think having a focused list would be an additional value to having the conversations scattered on various lists.  

 

Maybe something like… "After you had heard the discussions on the various options and you wish to indicate your opinion, please send your comments to "somelist@mitre.org".  Your comments will be read by the CVE Team and Editorial Board members. We greatly appreciate your input on this important community decision." 

 

While this approach could be a great deal of reading, it will anyway if we are going to do it right.  This just makes it a bit easier than chasing dialogs that spawn off, etc..

 

Does MITRE have intentions of getting press on this issue so those that are not on the relevant lists hear of the effort and the RSA events?

 

Looks as if you have reduced it to three real options….

 

Thanks.

 

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

 

From: "Steven M. Christey" <coley@mitre.org>
Reply-To: "coley@mitre.org" <coley@mitre.org>
Date: Friday, January 18, 2013 11:28 AM
To: "cve-editorial-board-list@lists.mitre.org" <cve-editorial-board-list@lists.mitre.org>
Subject: CVE ID syntax down-select complete - Public Feedback to begin

 

All,

 

On Tuesday January 15, MITRE CVE team members performed the down-select to

three different options for the CVE ID syntax change.

 

Those options are covered in the document I've included below, along with

strengths and limitations of each.  We will solicit public feedback

beginning with this document.

 

We are forwarding the document to the Board as a heads-up.  Next Tuesday,

January 22, we will be posting it to some relevant mailing lists and

sending individual updates.  We are planning to have some open discussion

and a Board meeting at RSA, followed by a formal Board vote - more details

to follow.

 

Thank you for your input and insights!  It's going to be an interesting

couple of months :-)

 

 

Regards,

Steve and the rest of the CVE team

 

 

 

===============================================================================

 

CVE ID Syntax Change - Call for Public Feedback

-----------------------------------------------

 

Due to the increasing volume of public vulnerability reports, the

Common Vulnerabilities and Exposures (CVE) project will change the

syntax of its standard vulnerability identifiers so that CVE can track

more than 10,000 vulnerabilities in a single year.  The current

syntax, CVE-YYYY-NNNN, only supports a maximum of 9,999 unique

identifiers per year.

 

Since a change in the ID syntax will affect many parties including end

users and vendors, the CVE project is soliciting feedback from the

public before making this change.

 

The public feedback period will continue through the RSA Conference in

February 2013, where attendees will be able to speak with CVE

personnel from MITRE and members of the CVE Editorial Board.  After a

formal Editorial Board vote, the final selection will be made and the

public will be notified, probably in March 2013.

 

The syntax change is scheduled to go into effect on January 1, 2014,

so that people will have enough time to change their processes and

software to handle the new ID syntax.

 

With guidance from the CVE Editorial Board, we have identified three

options for a new ID syntax, detailed below.  If you wish to comment

on any of these options, please send email to cve-id-change@mitre.org.

Due to the high volume of replies that we expect to receive, we will

not be able to respond to every email message; however, we will

publish a summary of responses.

 

The three options are:

 

*) Option A (Year + 6 digits, with leading 0's)

 

    Examples: CVE-2014-000001, CVE-2014-009999, CVE-2014-123456

 

*) Option B (Year + arbitrary digits, no leading 0's except IDs 1 to 999)

 

    Examples: CVE-2014-0001, CVE-2014-54321, CVE-2014-123456

 

*) Option C (Year + arbitrary digits + check digit)

 

    Examples: CVE-2014-1-8, CVE-2014-9999-3, CVE-2014-123456-5

 

 

More details about these options are available at the end of this

message.

 

Thank you to the entire community for supporting CVE, and we look

forward to your feedback.

 

Regards,

The CVE Project

 

 

------------------------------------------------------------

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

------------------------------------------------------------

 

Example identifiers:

 

   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

 

Strengths:

 

   This CVE ID syntax will seem familiar to consumers who are used to

   the old-style syntax from 1999 through 2013, since there are 6

   digits instead of 4.  This might make adoption easier and minimize

   confusion.

 

   The syntax would avoid some ID parsing problems that could occur

   with the other schemes, such as inadvertent truncation or

   fixed-length assumptions that would cause the wrong ID to be

   extracted.  It would also support the use of multiple consecutive

   IDs that can be easily sorted and displayed without special logic.

   The fixed length might be a desirable property to some consumers or

   CVE-processing implementers; the other options have variable-length

   IDs.

 

   Some CVE-processing software that automatically extracts or

   publishes CVE identifiers might not need to be changed, if it

   already assumes that more than 4 digits could be used.

 

   There will be enough IDs to support up to 1 million vulnerabilities

   per year.  This is effectively future-proof for CVE, because CVE's

   scope is expected to remain largely restricted to vulnerabilities

   that have been analyzed by humans.  If more than 1 million IDs are

   required, this would represent such a large paradigm shift in

   vulnerability disclosure and tracking that the entire industry would

   not be able to manage the volume using today's practices.

 

Limitations:

 

   Immediately upon the first publication of an ID using this syntax,

   many CVE programs that assume the old-style syntax would stop

   functioning correctly.

 

   The larger number of digits could increase the risk of typos,

   especially with the leading zeroes.  Some consumers might

   intentionally remove leading zeroes, assuming the old-style 4-digit

   number.

 

 

 

---------------------------------------------------------------------

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

---------------------------------------------------------------------

 

Note: in this option, extra digits would not be added until at least

10,000 IDs are needed.  When necessary, only one additional digit is

added.  For IDs 1 through 999, leading 0's would be used to expand the

number to use 4 digits.

 

Example identifiers:

 

   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

 

Strengths:

 

   This CVE ID syntax will seem familiar to consumers who are used to

   the old-style syntax from 1999 through 2013; the numeric portion

   will just contain extra digits.  This might make adoption easier and

   minimize confusion.

 

   The initial change to 5 digits would support up to 100,000

   identifiers in a single year; 6 digits would support up to 1 million

   identifiers per year.

 

   Some CVE-processing software that automatically extracts or

   publishes CVE identifiers might not need to be changed, if it

   already assumes that more than 4 digits could be used.

 

   The ID syntax will not have an obvious change until 10,000

   identifiers are needed, which might give extra time to CVE users to

   adjust to a syntax change.  (Note that CVE might not require 10,000

   identifiers this year.)

 

Limitations:

 

   The ID does not have a fixed length, and ID parsing errors are

   likely.  Some CVE programs would incorrectly truncate the wrong IDs

   because of the assumption of 4 digits, which would cause confusion

   and incorrect mappings.  For example, CVE-2014-123456 might be

   truncated as CVE-2014-1234, which would identify a completely

   different vulnerability.

 

   This syntax is less "future-proof" than others.  If a change is

   needed from 5 digits to 6, some CVE-processing software might break

   because of built-in assumptions about 5 digits.  Thus, for this

   option, there would be two different periods of transition of the

   CVE ID syntax: the transition to 5 digits, and the transition to 6

   digits.  However, the second transition would be less severe, since

   it would only affect implementations that were not correctly fixed

   in the first transition.  Option C would only have one transition,

   and Option A would only have one transition unless there is a

   radical change in vulnerability disclosure practices that would

   require more than 1 million IDs a year.

 

   Because there is no apparent change to the syntax until 10,000 IDs

   are needed, this might prevent some CVE implementers from making

   changes until it is too late and the change has already happened.

 

 

------------------------------------------------------------

Option C: Year + arbitrary digits + check digit

------------------------------------------------------------

 

Note: the ID would consist of the year, a hyphen, a sequence number of

1 or more digits, another hyphen, and a single check digit calculated

using the Luhn Check Digit Algorithm, which is used in other

identification schemes such as credit card numbers.  This syntax is

similar to that used by the Common Configuration Enumeration (CCE);

see http://cce.mitre.org/about/faqs.html#B2 for more information.

 

Example identifiers:

 

   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

 

Strengths:

 

   This ID syntax supports arbitrary numbers of vulnerabilities, and as

   a result, it is future-proof.  The trailing hyphen and check digit

   serve as an unambiguous boundary that clearly decomposes the ID into

   three distinct parts, regardless of length.  CVE implementations

   that conform to this syntax would not need to be changed when the

   number of digits changes.

 

   The check digit would be useful for automatically detecting typos in

   identifiers.  Because of the widespread use of CVE, identifier typos

   cause significant confusion and maintenance costs to resolve,

   although the frequency with which this occurs is not clear.  Since

   there is a trend towards large-scale automation for managing

   vulnerabilities, the check digit would be very useful as part of a

   data integrity check of CVE IDs during computer-to-computer

   interaction.

 

Limitations:

 

   Immediately upon the first publication of an ID using this syntax,

   many CVE programs that assume the old-style syntax would stop

   functioning correctly.

 

   This ID syntax is the most radical change to the old-style syntax.

   It could cause confusion among CVE consumers who are unaware of the

   syntax change, since "CVE-2014-1-1" would appear to be a malformed

   ID compared to the old-style ID.

 

   Compared to other options, this ID would be more difficult to use in

   human-to-human communications.

 

   Parties who are familiar with the old-style ID syntax might

   inadvertently omit the check digit.  This could increase

   implementation costs or reduce usability for implementations that

   assume that IDs have the check digit.