Outline of CPE 2.3 and Beyond 21 April 2010

1. Outline of CPE 2.3 and Beyond21 April 2010 CPE Core Team: Brant Cheikes and Mary Parmelee (MITRE); Dave Waltermire, Paul Cichonski and Harold Booth (NIST); Jim Ronayne and Shane Shaffer (DOD) MITRE

2. Recap of February 2010 CPE Developer Days • Many proposed changes were discussed during the workshop including: • Allow for alternate forms of expression other than URI • Removal of the “prefix property” • Remove all meaning from CPE name • Add support for distinct namespaces • Provide an extensible vocabulary of terms • Revise the matching algorithm • Break-up the specifications • Maintain backwards compatibility with CPE 2.2 • CPE Core Team has created an outline of what is proposed to be included in CPE 2.3, and what would be left for a CPE 3.0 release. • During this process the Core Team took into consideration the requirements of the SCAP adoption and release lifecycle. • The Core Team also considered the short timeframe in which CPE 2.3 changes must be implemented and the potential disruption to SCAP adopters based on proposed changes.

3. All decisions were made while considering the short time frame for the CPE 2.3 release • CPE 2.3 will be considered for inclusion in SCAP 1.2 • All specification work for SCAP 1.2 must be completed by July 2010 for consideration • Draft for 30-day public comment must be released June 11 • All new functionality within CPE 2.3 must adhere to SCAP adoption guidelines, including: • The existence of a reference implementation for the specification(s) • The demonstration of uptake by vendors, agencies and organizations • Due to the short time frame, changes implemented in CPE 2.3 must address immediate community concerns while minimizing risk to adopters • Small number of changes to limit potential disruption during release of SCAP 1.2 • Provides the basis for innovation of future capabilities to address larger community needs

4. Proposed Changes for CPE 2.3 MITRE

5. CPE 2.3 will break up CPE into multiple specifications • Each component specification will represent a logically separate function • Will provide the basis for future innovation by allowing the disparate functions to evolve independent of a single release cycle • The component specifications will be: • Naming Specification – Defines how CPE names are constructed • Dictionary Specification – Defines all functionality relating to the CPE dictionary • Matching Specification – Defines how CPE names (with wildcards) are used in matching • Language Specification – Defines how the CPE language works

6. Naming Specification:Taxonomy of CPE Name Types Basic Name Most general kind of well-formed name, defined generically as a collection of attribute-value pairs. Query Name KnownName A well-formed name that is recognized by some organization. This would normally be used to represent in-house products. A well-formed name that is used to define a search criteria for looking up Known or Official CPE Names. This name may contain wildcards. Authoritative Name A known CPE name that has been recognized by an authoritative community organization and published in an authoritative dictionary

7. Naming Specification:Well-Formed Names • Agnostic to binding (encoding for transport) • A set of attribute-value pairs • Attributes taken from fixed vocabulary (the 2.2 component names) • Values are character strings • Want to eliminate percent encoding (options being evaluated) • Want to eliminate prefix-property requirement (separate proposal forthcoming)

8. Naming Specification:Query Names • A Query Name is a well-formed CPE name used to search dictionaries for potential matches • When used for search purposes, certain value strings (as well as certain characters embedded in value strings) are interpreted as wildcards

9. Naming Specification:Known and Authoritative Names • Known Names • A well-formed name that has been published in some organization’s dictionary • Authoritative Names • A well-formed name that has been published in a dictionary recognized within the community as a source of authoritative names • Use of authoritative names only (when such names exist) should offer a guarantee of interoperability

10. Naming Specification:Bindings • Bindings are the way abstract names are encoded into machine-readable form for transport and processing • For backwards compatibility with 2.2, we may need to preserve the URI binding • We might be able to define a new “formatted string” binding which looks like a URI • Concern: if we relax the rules on percent encoding, would that make v2.3 names indigestible by v2.2 tools?

11. Naming Specification:Likely out of scope for 2.3 • Adding any attributes beyond the existing seven • Unpacking the edition field • Existing dictionary too inconsistent to readily support mechanical parsing of existing “edition” component values into target HW, target SW, and software edition • Unclear how to mechanically “repack” three distinct values into one

12. Dictionary Specification:Goals • Define the format of a CPE Dictionary Entry • A well-formed CPE name plus additional metadata • Encoded using XML Schema • Distinguish between an authoritative dictionary curated by NIST and private dictionaries which are curated by others • Submission process defined in a separate document, pointed to in the specification but not itself part of the specification

13. Dictionary Specification:Concrete Names • We are considering whether to restrict dictionary entries to “concrete” names • Concrete means, names which have no embedded wildcards, do not denote collections of other products/platforms, and have a value for every attribute (even if that value is “not applicable” • Lots of issues still to be sorted out here • Forthcoming slides on Dictionary specification will provide more detail

14. Matching Specification:Goals • Clarify and simplify the v2.2 definition of matching • Developing ideas for a new matching algorithm which might allow us to eliminate the “prefix property” • Support limited use of wildcard characters embedded in value strings (‘*’ and ‘?’)

15. CPE Language Specification:Goals • Reuse the v2.2 language definition with as little modification as possible

16. CPE 2.3 will only provide a short term solution, extensive changes may be necessary in the future • CPE 2.3 represents what can be done in the very short time frame we have available to work • Fixes smaller problems, minimizes vendor disruption • Does not address majority of community concerns • Once CPE 2.3 is finalized work can begin on a more robust 3.0 solution to address community problems • A longer timeline to allows for: • The establishment of community working groups to drive future CPE activities, including development of specifications, reference implementations, governance policy, and vendor adoption • The community to test proposed changes before implementing them in a formal version of SCAP

17. Milestone Schedule • 14 June : CPE session at SCAP Developer Days. • 11 June: Draft specs released; beginning of public comment period. • 9 July: Close of public comment period; 2 weeks to respond to comments. • 23 July: Final CPE v2.3 specs are delivered to NIST for consideration for inclusion in next release of SCAP.

18. Concluding Remarks • CPE 2.3 will aim to: • Introduce a taxonomy of name types • So we can properly talk about names that have different properties depending on use case/operational context • Add flexibility in how names are represented and encoded for transport and processing • Eliminate the prefix property and its impacts • Allow limited wildcards in matching • Move us closer to a major 3.0 revision which will provide a more robust solution for the future