[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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: 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.