CVE ID Syntax Change - Voting Ballot (Deadline April 14, 11:59 PM EDT)

["Andy Balinsky (balinsky)" <balinsky@cisco.com>]

=====================================================
VOTING BALLOT
=====================================================

FIRST CHOICE: OPTION C


REASONS (first choice): 
We feel Option C is overall the best technical solution to the problem. It minimizes the possibility for transcription errors, as well as eliminates long strings of leading zeros. 

We like the combination of not having the distracting leading zeros, as well as having the check digit to be sure that you have a complete ID. The downside of the check-digit would be to add complexity during a human-typed search. We feel that most tools could work around this by allowing searches for partial CVEs. This would allow human users to leave off the check digit during a search, and still pull up the vulnerability. The main purpose of the check digit is for publishers of vulnerabilities to ensure that references to their vulnerability use the correct ID. It would also be useful for tools that produce reports of some type, to be sure that they have precisely identified the vulnerabilities they are reporting. 

As far as the nature of the check digit, we recommend the Verhoeff or Damm algorithms, rather than the Luhn algorithm. Both algorithms can detect more transpositions than the Luhn algorithm. The Luhn algorithm's only advantage is that it is more easily hand-calculable. We don't feel that anybody will be calculating these by hand, so the Luhn algorithm is inferior in all respects for this purpose. 

*****************************************************

SECOND CHOICE: OPTION A


REASONS (second choice):
We feel that this is the most human-friendly format. 
It is superior to Option B, in that the length is well-defined, and you know whether you have a complete CVE-ID or not. You can be sure it hasn't been truncated in email or otherwise. As to the obvious downside of A, being the inability to handle 1,000,000 vulnerabilities in a single year, we felt that this was rather unlikely to occur, and thus, not a significant limitation. If there were some need to catalogue 1,000,000 vulnerabilities in a single year, the current CVE scheme would be inadequate to the task, and something else would likely take its place. 

The reason we rate this behind option C is that we feel that the need to provide a large number of leading zeros for many vulnerabilities would lead to transcription errors and ambiguities. How would you interpret CVE-2014-00007, for example? Is it completely invalid? Is it intended to be CVE-2014-000007, and we're missing a "padding zero", or is it intended to be CVE-2014-00007x, and the last digit has been truncated?

From a user search perspective, if option A is selected, we would encourage tools to make the leading zeros optional during a search. In other words, if a user searches for CVE-2014-7, that the search results should include CVE-2014-000007 (as well as, optionally, CVE-2014-00007X, CVE-2014-0007XX, etc. where X represents any digit from 0-9). But users who search for a lot of vulnerabilities are going to get tired of typing and counting leading zeros, which is why we favor being allowed to omit them for a search. It is also why we favor option C, which has no leading zeros. 
*****************************************************

LAST CHOICE: OPTION B


REASONS (last choice):
We feel that the completely open-ended nature of option B opens up too much room for errors. Option C is a better way to provide for open-ended vulnerability numbers. It is just too hard to tell whether you have an incorrectly-typed CVE-ID using option B. And, as we don't feel that the need for cataloguing > 999,999 vulnerabilities in a single year is at all likely, option B has no real advantages to speak of, compared to the other 2 options.