Open Security Foundation (OSF) - CVE ID Syntax Change Second Round Voting Ballot
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:
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)
: 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
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.