I don’t think it’s possible to change the format in any way without breaking someone’s implementation somewhere. “CVE-\d{4}-\d{4}” might match, but “^CVE-\d{4}-\d{4}$” might not – or “/CVE-(?P<year>\d{4})-(?P<id>\d{4})/$”,
etc.

Overall, I think either
Option 1 or Option 7 are the best. I think they match up against the considerations thusly:

- Both have a large ID space

- Both are easily recognizable as CVEs

- Option 1 is probably more easily adopted than Option 7 as Option 7 has an additional field and the validation aspect.

- Option 1 is probably simpler to adopt in terms of updating software. Option 1 is likely already matched by many existing regular expressions in use for locating CVEs.
Option 7 can be matched by a regular expression but the validation would need to occur separately.

- Option 1 delays impact longer than Option 7

- Option 7 is immediately recognized as the new syntax. However, Option 1 is also easily recognized as the new syntax once it matters that the syntax is different.

- As long as the number of digits is not limited both appear to be fairly future-proof.

Option 7 below looks the best to me. I would expect most implementations to ignore the check digit, but it’s nice to have, and makes it easy to identify the newer format. It could probably be improved
by padding fewer than 4 digits with 0s, like suggested for Option 1 (for compatibility). My concern with something like Option 1 is that nobody will notice that there is a new standard until CVE-2013-10000 is released, and a bunch of implementations suddenly
break.

Options 5 and 6 are probably the worst options. They’ll break existing implementations in a bad way (anything trying to parse ints).

Option 8 loses the year completely – I think a lot of people would take issue with that. Also, breaks most existing implementations.

More Details:

Option 1: Year + arbitrary digits, no leading 0's

--------------------------------------

Examples: CVE-2013-1234, CVE-2013-12345 (if 4 digits or less, leading

0's would be used, e.g. CVE-2013-0056 instead of CVE-2013-56)

nCircle Feedback: I think this is the logical extension of the current ID format. It seems obvious to me that CVE-2013-10000 would be the next ID issued after CVE-2013-9999. Since the fields
are dash-delimited the ID space is basically unlimited. The only downside appears to be that standard alphanumeric sorting doesn't place 10000 after 9999 but this is an issue that comes up many times in software engineering and I consider it to be a basically
solved problem. I don't think this format should be rejected just because of lazy coders.

Option 2: Year + 5 digits, leading 0's

--------------------------------------

Examples: CVE-2013-01234, CVE-2013-56789

nCircle Feedback: I don't like specifying the maximum number of ID digits because it's limiting and just because 1,000,000 seems like a big number for identified vulnerabilities now doesn't
mean it will remain a big number in the future. I also don't care for leading zeros, which these two options require.

Option 3: Year + 6 digits, leading 0's

--------------------------------------

Example: CVE-2013-012345, CVE-2013-678901

nCircle Feedback: Options 2 and 3 don’t seem very useful. They will immediately break some existing implementations, and just set another arbitrary limit.

Option 4: Non-standard year + 4 digits

--------------------------------------

Example: CVE-1013-1234, CVE-3013-1234 (instead of using the current

year, a year before 1999 or after 3000 could be used once 10,000 is

reached in a single year)

nCircle Feedback: I find that having the year in the ID is extremely helpful and since this scheme obfuscates the year once 10,000 bugs are reached I don't care for it. This also breaks
standard alphanumeric sorting because CVE-3013-0001 will end up after CVE-2014-0001. Sorting can be fixed but this is a less standard sorting problem than the one in Option 1.

Option 4 would break sorting, and just be very confusing in general. The “year” part effectively becomes useless.

Option 5: year + 4 hex digits

-----------------------------

Example: CVE-2013-A9E4

nCircle Feedback: I think this is an ok option but as long as the format is going to change I don't think the number of digits should be limited. Since the last part is still a numerical
value it's easier to sort than Option 6.

Option 6: year + 4 alphanumeric

-------------------------------

Example: CVE-2013-ZW1K

nCircle Feedback:

I don't care for this option because it moves away from numerical values in commonly used bases. I guess the value could be treated as base 36 but I'd rather go with Option 5 than Option 6, especially
if the number of digits wasn't limited to 4.

Option 7: CCE-Style (year + arbitrary digits + check digit)

-----------------------------------------------------------

Example: CVE-2013-12345-6 (the "6" is a check digit, following the

Luhn Check Digit Algorithm)

nCircle Feedback: I think this is the best option. I like that the new format can be immediately recognized because it contains three dashes instead of two. As with Option 1, the sorting
will need to be handled to make sure that adjacent CVEs appear next to each other in lists but as I've said before that should not be a problem.

Option 8: CERT-VU/JVN Style

---------------------------

Example: CVE#12345678

nCircle Feedback: I think this format is unacceptable because the year is omitted. As I said before, I find having the year in the ID to be extremely useful.