Re: CVE ID Syntax Vote - results and next steps

[Carsten Eiram <che@riskbasedsecurity.com>]

On Fri, Apr 19, 2013 at 12:05 AM, security curmudgeon <jericho@attrition.org> wrote:

On Thu, 18 Apr 2013, Kent_Landfield@McAfee.com wrote:

If both were changed as mentioned above, where A was 7 digits intead of 6,
and B had no leading zeros at all. I am really curious how people would
vote.

: Using his logic, we could make it 10+ digits and not pad it with leading

: zeros.  Then it would be capped at a static length but we would only
: have to use what we need.  It could grow as needed and we would have the
: future proofing that is a major reason stated by those who voted for
: Options B.  The end user would see a CVE ID that is reasonable from a
: readability perspective, software would have a static length that we can
: grow into. An approach like this could potentially go a long way to
: getting to a consensus majority.
:
: Thoughts?

Overall I like it. We're addressing the problems with the proposed
solutions, and building on them, rather than coming up with additional.

It would be great if every member would weigh in on the above, not as an
official vote, but just to see if either has more benefit, or to add other
options and ideas.

I would still lean towards the revised option 'A' as it's a fixed length, but it would make the revised option 'B' more appealing, as one concern was the "leading zeroes up to 4 digits" format. Another concern with option 'B' is the lack of being able to detect possible truncation errors.

/Carsten