[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVE ID Syntax Vote - results and next steps

  • Do you prefer fixed length or variable length? 
FIxed length (in the absence of the seemingly unpopular check digit.) 

Our staff that deals in searching on CVE's on a daily basis would also greatly appreciate tools that allowed matches on partial CVE's (e.g. if they interpreted CVE-2014-1 as CVE-2014-000001. This would be especially true if the number of digits expanded to 9, 14, or whatever. It is a pain to count all those zeros every time you search.)  But note that this would only be for searching. We would still advocate that people publish new CVE's with the full digit range. Publishing is a one-time event per CVE, where as searching may be done many times, as you are researching product vulnerabilities. 
  • If you prefer fixed length, what field length do you consider sufficient? 
6 digits. 


On Apr 25, 2013, at 10:24 AM, <Kent_Landfield@McAfee.com>

From: <Booth>, Harold <harold.booth@nist.gov>
Date: Wednesday, April 24, 2013 9:17 PM
To: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: RE: CVE ID Syntax Vote - results and next steps

While I believe I understand what is being asked based on prior context in the conversation I would like to verify my assumptions.
By static length I am assuming that a maximum length will be specified as opposed to unlimited length as the previous options B and C indicated. I would like to see the question of padding with zeros separated from the length question.
I would also like to suggest we may want to use different wording for these choices in the future since it is possible to interpret static length to indicate an identifier with the same number of digits at all times, likely padded with zeros, while variable length could be interpreted to indicate an identifier that is not padded and just contains the significant digits.
  • Do you desire a static length of the CVE Ids? 
Yes, a specified maximum length is much easier to write parsing and validation logic for and at the end of the day everyone will have to decide on some sort of cut-off.
I have no strong opinions on whether or not the identifier should be padded other than to note that an identifier without padding leaves open the possibility of an extended transition time while an identifier with padding will require an abrupt switch. Unless there is a strong reason for a padded identifier (and I would be interested in hearing about any that exist) I would think the benefits of a longer transition period would tilt in favor of no padding.
  • If so, what length do you feel would be acceptable to you?
  • -- 6 — 7 — 12 — More? -- Something else?
I believe 9 digits would be sufficient. It’s not so many digits that it would be overwhelming but leaves flexibility for accommodating some of the scenarios Steve hints at below.
- Any comment on Adam’s suggestion of trailing zeros?
It is ambiguous for numbers divisible by ten, for example imagine if CVE today had trailing instead of leading zeros and we had the following number:
Is this a 1 with three trailing zeros? A 10 with two trailing zeros? A 100 with one trailing zero? or 1000 with no trailing zeros?
From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of Boyle, Stephen V.
Sent: Wednesday, April 24, 2013 6:18 PM
To: cve-editorial-board-list
Cc: Boyle, Stephen V.
Subject: RE: CVE ID Syntax Vote - results and next steps
We greatly appreciate the discussion that has taken place since the vote, and we are (as always) truly grateful for a thoughtful, engaged Board; thanks to all.
MITRE agrees that a second vote is necessary and prudent, and we agree that Option C has been eliminated from further consideration.
With regard to the identifier length discussion: one email quoted before lays out the scale of the fixed, 6-digit number field of the identifier. Paraphrased, anything more than 999,999 CVE IDs in one calendar year would necessitate the issuance of 3,968 CVEs per day presuming the normal 252 MITRE work days per year. (The “over 2,700” original number was based on 365 work days.)
While the idea of ~4,000 CVEs per work day seems incredible to me, I was also there at the beginning when it was decided that 10,000 CVEs per year was outlandish. I am very sympathetic to the point that we don’t know what we’re going to be doing in the future. As one possible example, some people have talked about a “global” CVE with tiers of CNAs (which I prefer to not discuss here and now). I personally don’t think such a  hierarchical scheme is practical or feasible (beyond the current two levels of MITRE and CNAs), but I didn’t think > 9,999 CVEs per year was practical or feasible, either. In addition, we have been working on our infrastructure, work flow, and staffing so that we are positioned to increase our throughput and potentially decrease response time based on available funding.
I haven’t heard about people trying to save bits on disk for quite a while, so the idea of 7, 8, 9 … characters in a fixed-length number field of the identifier feels kinda the same to me, especially when considering the ID field length as a percentage of the average number of characters in a CVE entry (ID, Description, References).
We would really like to see some responses to Kent’s suggestion of a poll – a straw vote, if you will. Kent’s suggestion was:
Can we have a quick poll on the combined set of existing options and the ones Art has listed below?  I'd think a re-whittling of the choices may get us to a better place to conduct a vote. 
  • Do you desire a static length of the CVE Ids? 
  • --Yes — No
  • If so, what length do you feel would be acceptable to you?
  • -- 6 — 7 — 12 — More? -- Something else?
Put another way:
- Do you prefer fixed length or variable length?
- If you prefer fixed length, what field length do you consider sufficient?
- Any comment on Adam’s suggestion of trailing zeros?
We’d like to hear from the Board on this so that we can shape the set of options for consideration for a second vote. Both eligible Board voters and non-voters are welcome to comment. Your prompt and thoughtful attention on the topic will be very much appreciated.
Thank you again for your engagement and thoughtful responses.
Best Regards,
Steve Boyle
CVE Project Leader

Page Last Updated: June 26, 2013