Develop a Unified CPE Support RFD

[alilleybrinker]

In the discussion on the RFD for Software Identifiers, @Chris-Turner-NIST raised compelling points about the need to improve CPE handling in the CVE Record Format.

If the intent is to create more generic places for various identifiers, it would make sense that part of this proposal should include deprecating the existing cpes array and include a new property (cpeMatchString?) that aligns with the approach proposed for PURL and OmniBOR.

I recognize that this would create two locations for CPE related data due to the current support for hasCPEApplicability, however, it would be a step in the right direction of normalizing the current structures and methodologies available within the affected array.

To that I'll add that, given the cpeApplicability block added last year, there are currently two ways to put CPEs in a CVE Record, in the cpes array in product objects of the affected array, or in this cpeApplicability block. If the cpes field were deprecated in favor of a new field in line with the pattern established in #407, we should also strive to address the inconsistency raised by the existence of cpeApplicability.

I think this deserves an RFD, with the goal of eventually transitioning the CVE Record Format to a form where there is one and only one place to put CPE data.

[darakian]

Something that would be good to have documented along side this is how organizations can go about reserving/registering CPEs. I know that's more an NVD thing than a CVE thing, but coordinating with NVD to ensure there's a clear path/set of expectations would be good to do for anyone new to the CVE world.