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

[<Kent_Landfield@McAfee.com>]

Doodle works for me...

Kent Landfield
McAfee Labs
Kent_Landfield@McAfee.com
+1.817.637.8026 

On Feb 15, 2013, at 12:41 PM, "Boyle, Stephen V." <sboyle@mitre.org> wrote:

> Cool -- thanks TK!
> 
> All: Tuesday and Wednesday have been mentioned as possibilities. Do people want to just respond to the list or should we arrange a Doodle for polling?
> 
> Steve (Boyle)
> 
> -----Original Message-----
> From: Tim Keanini [mailto:tkeanini@ncircle.com] 
> Sent: Friday, February 15, 2013 1:35 PM
> To: Boyle, Stephen V.; Kent_Landfield@McAfee.com; cve-editorial-board-list
> Subject: RE: CVE ID syntax down-select complete - Public Feedback to begin
> 
> Let me offer my offices on 2nd and Mission but we will need to coordinate a time so I can get the big meeting room.
> --tk
> 
> Chief Research Officer, nCircle...blog: patterns.ncircle.com.mbl: 415.328.2722.twtr: @tkeanini
> 
> -----Original Message-----
> From: owner-cve-editorial-board-list@LISTS.MITRE.ORG [mailto:owner-cve-editorial-board-list@LISTS.MITRE.ORG] On Behalf Of Boyle, Stephen V.
> Sent: Friday, February 15, 2013 12:28 PM
> To: Kent_Landfield@McAfee.com; cve-editorial-board-list
> Subject: RE: CVE ID syntax down-select complete - Public Feedback to begin
> 
> Hi Kent - thanks for the ping on this topic.
> 
> To all: 
> 
> To date, we have not been able secure room space for our planned meeting. (Unfortunate, but not surprising, given that for the CVE 10th anniversary we booked in October. :-)
> 
> We are actively working alternate arrangements and we are on the wait list for rooms in multiple convenient locations. 
> 
> We will update the Board as soon as we can nail something down.
> 
> Best Regards,
> Steve Boyle
> -----------------------------------------
> From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of Kent_Landfield@McAfee.com
> Sent: Wednesday, February 13, 2013 11:32 AM
> To: Christey, Steven M.; cve-editorial-board-list
> Subject: Re: CVE ID syntax down-select complete - Public Feedback to begin
> 
> All,
> 
> RSA is fast approaching and scheduled meetings are getting set in stone.  Have we made a decision as to when the CVE Editorial Board meeting and CVE Format discussions will be held?  I want to make sure I have that time available for attending.  Hope to see most of you there!
> 
> 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.