« November 2012 | Main | April 2013 »

1 post from February 2013

Feb 13, 2013

CVE is about to undergo a change in syntax for CVE identifiers

Hello, it's Taki here and it has been a long time since I last wrote here.

Today's topic is about the following:


Call for Public Feedback on Upcoming CVE ID Syntax Change
https://cve.mitre.org/news/index.html#jan242013a


Before I get into the details of what is said here, I would like to quickly introduce CVE. CVE stands for Common Vulnerabilities and Exposures and it is managed by The MITRE Corporation in the US. CVE identifiers are unique, common identifiers for publicly known information security vulnerabilities. For more details on CVE identifiers, please refer to the following:


About CVE Identifiers
https://cve.mitre.org/cve/identifiers/index.html


So getting back to the discussion topic, CVE is about to undergo a change in the syntax for CVE identifiers. The current syntax, CVE-YYYY-NNNN can only support a maximum of 9,999 unique identifiers for a given year.

There are many users of CVE across the globe and a syntax change may affect a number of users, thus the CVE project is soliciting feedback prior to changing the syntax.

There are 3 choices to choose from, and I will list them in my order of preference with some reasoning behind its placement. (For details on the exact syntax for each option, please refer to the MITRE announcement)


1. Option A
This requires the least change, and I expect users that are already familiar with the current CVE syntax should be able to make the transition without too many issues. Being a little selfish, since this option requires the least change, it would make it easier to explain the differences to newer users of CVE and why they were made.

2. Option C
This is quite a drastic change from the current syntax but with the inclusion of the check digit, it would allow users to verify that the CVE identifier is a valid one. However, this syntax may be a little difficult to handle for product developers that incorporate CVE identifiers into their products.

3. Option B
I went back and forth a little between Options B and C. But the check digit that allows for validation (albeit a simple method) made the choice for me. In my opinion, it would be hard to determine whether that ID is a valid one since the number of digits would be arbitrary.


JPCERT/CC has been working with MITRE since 2008 to have CVEs issued for advisories on Japan Vulnerability Notes (JVN). Since then, JVN has become CVE compatible and JPCERT/CC has become a CVE Numbering Authority (CNA). As a member of the vulnerability handling team, I have listed my opinions here and would certainly welcome any feedback or discussion.

As mentioned on the MITRE announcement, there is a mailing list for discussions as well.

Any questions should be directed to the mailing list, but if you would like to have a discussion offline, please feel free to contact me at vultures(at)jpcert.or.jp.

- Taki Uchiyama