Re: CVE ID Syntax Vote - results and next steps

[Pascal Meunier <pmeunier@cerias.purdue.edu>]

I made a list of the desirable properties of CVE identifiers, based on the
votes and discussion.  I believe that by weighing those, our situation may
be clearer.  A CVE identifier should (in no particular order):

1. Be immutable once issued: references should not change, like a DOI (Digital
Object Identifier). When the format is changed, the new format should apply
only to newly issued CVE IDs.  This is different from wanting to delay a
change, and can in theory allow any number of changes.

2. Have a consistent (elegant, not ugly) numbering method and format: the format
should follow a "standard method".

3. Have a format that will accommodate future numbering needs.

4. Have a format that will help make transcription errors evident, or easily
detectable (example errors: dropped digits, "fat finger"). 

5. Have an easily readable format (for humans).

6. Have a format that is similar to the current one.

7. Have a format that is easy to handle by machines (read, decoded, sorted). 

8. Delay a format change as long as possible.

9. Have clear storage or internal representation requirements (e.g., 64-bit
integer).

10. Have a format similar to that used by other identification schemes
(e.g., CCE) so parsing libraries can be reused.

11. Avoid complexity (e.g., extra check digit).


Option A: 2, 3, 4, 5, 7, 9, 11
Option B: 1, 3, 5, 6, 8, 11
Option C: 3, 4, 7, 10

Option A' (no leading 0s, capped at static length): 2, 3, 5, 7, 9, 11
Option B' (no leading 0s): 2, 3, 5, 7, 11

Option A is superior if equal weights are used.  I believe #1 and #8 should
have more weight, so I prefer option B.  #1 is an academic principle, #8 is
practical.  #1 could be satisfied by applying option A only from 2014 forward;
if this was considered, I'd vote for it.  

Pascal