Re: CVE ID Syntax - Please Vote

[Matt Bishop <mabishop@ucdavis.edu>]

Hi, all,

From the academic research side :-)

Matt

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

Enter your votes as specified in the preceding "Instructions" and
"Filling out the ballot" sections.



FIRST CHOICE: Option C


REASONS (first choice):

The "arbitrary digits" is a bit harder to parse than a fixed width of 6 digits, but it allows more growth -- I *hope* we never get beyond 999,999 vulnerabilities a year, but on principle, I don't like locking into a fixed size field. As for the presence of a check digit, this is useful for ensuring the CVE number is copied right. The algorithm for this, I am assuming, is very simple (like the credit card one or a parity one), and not something like adding the results of a SHA-whatever hash together :-) 




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

SECOND CHOICE: Option B


REASONS (second choice):

See option C above. The lack of a check digit makes this choice #2. But I consider these two close, and won't weep if either of them are adopted.



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

LAST CHOICE: Option A


REASONS (last choice):

The fixed field size grates on me. It would be easy to miscount the number of leading 0s, and as there is no check on the CVE number, this could mess up parsers that require all 6 digits to be present. And if the parser doesn't, this defaults to Option B. It's acceptable, but seems to me to be too rigid and easy to mess up.