Open Security Foundation (OSF) - CVE ID Syntax Change Second Round Voting Ballot

[security curmudgeon <jericho@attrition.org>]

On Tue, 7 May 2013, Boyle, Stephen V. wrote:

: CVE ID Syntax Change - Second Round Voting Ballot 
: - Deadline May 22, 2013, 11:59 PM EDT

Before I vote, I want to go on the record saying that this has become a 
choice between two evils. I am not happy with either format and believe 
that the board has done a disservice to the industry. Personally, I 
believe that many on the board have completely forgotten the reason the 
board was formed, and are using their position to provide influence 
specific to their own desires, or the desires that best suit *their* 
organization. As a reminder:

http://cve.mitre.org/community/board/

   The MITRE Corporation created the CVE Editorial Board, moderates Board 
   discussions, and provides guidance throughout the process to ensure 
   that CVE serves the public interest.

Please note that last bit; the public interest. Now, re-read the prior 
votes and consider that.

   "Most of our tools and processes already support this method."

   "Future proofing is important to $MYCOMPANY."

   "... we don't want to confuse our consumers with a significantly 
    different numbering scheme."

For many board members, this clearly isn't about the community. This is 
about your company, and your consumers, which is ultimately your profit 
center. That, is not the public interest.

As for the vote, the following is how the Open Security Foundation (OSF) 
is voting:

: FIRST CHOICE:

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

: REASONS (first choice):

Only slightly lesser evil than the other option, the future proofing is 
obviously beneficial. Since previous years will keep the 4-digit format, 
this option will build on that, adding the extra digit as needed. OSF 
thinks that this slightly outweighs the negative aspect of transcription 
error frequency, that we feel will increase. Really, you have seen 
disclosures lately, right? Many of them can't present their own 
vulnerability findings without typos and errors. We already see typos in 
the current CVE scheme from large vendors and vulnerability broker 
services. 

That said, this option is unfortunately the way to go.

: *****************************************************
: 
: SECOND CHOICE:

OPTION A: Year + 8 digits, with leading 0's

: REASONS (second choice):

Moving to 8 characters is complete overkill and devalues the format, 
making OSF feel this no longer is the best solution for the industry at 
large. The standard length is a great benefit to help ensure accurate CVE 
numbers are used between researchers and organizations. However, too many 
leading 0s will also lead to transcription errors.

If Steve Christey issues CVE-2014-01234567 for the 'Sushidude-in-Pumps 
Tequila Overflow', I can be sure that the number is properly formatted, 
and that in his drunken stupor he has not dropped a digit. Using the other 
option, any number he sends me cannot be validated quickly with the 
varying length. And we all know he is a shady character. But, if he has to 
issue CVE-2014-00000012, that is just as likely to get murky as us old 
geezers squint to count the zeros. I could have added an extra 0 to that 
last example, and I bet no one would have noticed.

Since prior years will continue to use the 4 digit format, instead of 
converting to lead padding to maintain a truly universal identifier, this 
also means that the primary strength of this format is lost, as we are NOT 
using a fixed-length identifier. We're using a fixed length of 8 digits 
only for 2014 on. If we're going to use varied length identifiers, this 
becomes the slightly more absurd/evil option.