FIRST CHOICE: Option B
Future proofing is important to McAfee. Our selection of Option B as our first choice, provides CVE with the ability to expand as needed in the future. Additionally,
this option allows for the least impact to the existing user community. Customers are familiar with the existing format and the change to the new format will be much easier to explain and incorporate into our products. Our software today is able to use this
format without major changes such as would be required by the check digit option. We may have voted for option A if there were more than 6 digits specified, but felt 6 digits did not provide the future proofing we desired. McAfee does not want to see ourselves
back in a situation were a change is needed to the CVE format yet once again.
We have seen and support the Luhn check digit used in another enumeration, CCE. It has not been useful from our perspective and we do not see it being all that valuable in the future. Option C and it's check digit is also potentially very disruptive to
the security community as a whole. Unlike the previous two options, reasonable code changes would be unavoidable and required by this option. This would impact a great deal of software, including open source, commercial products, and internal operational
use. This option has the potential for causing the greatest failures and confusion for the community. Customers and the user community at large would have to be educated as to what the Luhn digit is and why it is there. The CVE format is recognizable and
understood today. Besides recognizing and processing the new CVE format, software that processes CVE Ids would have to process the older format as well. This complicates getting the change to the field as the software changes would need to be made in all
products that support CVE moving forward. The impact required by the forced software changes, combined with the initial customer and community confusion were the reasons this was our least favorable option.