Re: CVE ID Syntax Vote - results and next steps
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
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.