[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

 

  • If you prefer fixed length, what field length do you consider sufficient? 9 digits

 

  • Any comment on Adam’s suggestion of trailing zeros? It would be confusing as indicated in Harold's answer and I see more problems than value.

 

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.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:

1000

 

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?

 

Regards,

 

-Harold

 

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 or Reviewed: October 03, 2014