1 / 32

CPE Naming Specification Outline

CPE Naming Specification Outline. CPE Core Team: Brant Cheikes and Mary Parmelee (MITRE); Dave Waltermire, Paul Cichonski, Harold Booth and Chris McCormick (NIST); Jim Ronayne and Shane Shaffer (DOD); Seth Hanford (Cisco); Kent Landfield (McAfee); Tim Keanini (nCircle). MITRE.

kateb
Download Presentation

CPE Naming Specification Outline

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CPE Naming Specification Outline CPE Core Team: Brant Cheikes and Mary Parmelee (MITRE); Dave Waltermire, Paul Cichonski, Harold Booth and Chris McCormick (NIST); Jim Ronayne and Shane Shaffer (DOD); Seth Hanford (Cisco); Kent Landfield (McAfee); Tim Keanini (nCircle) MITRE

  2. CPE Specification Stack • The diagram below illustrates the stack relationship among the various specifications comprising v2.3 of the Common Product Enumeration (CPE) standard. • Naming is at the bottom of the stack—it defines a the general concept of a well-formed name • Defines the logical structure of well-formed names, and requirements on attributes and values used to form names • Provides informative guidance relating to the use of names and the different contexts where they may be used Language Dictionary Matching Representation (Binding) Naming

  3. CPE 2.3 Naming Specification Executive Summary (1) • In v2.3 we introduce new features in CPE names that make those names non-conformant with the v2.2 specification • We distinguish “v2.2 conformant names” from “v2.3 conformant names” • We define a mechanical translation between versions of names • We define a Well-Formed Name (WFN) as a referring expression • Interpretation depends on context of use

  4. CPE 2.3 Naming Specification Executive Summary (2) • We define a WFN as a conceptual data structure which can be bound to a version-conformant machine-readable representation • We retain the URI binding for backward compatibility w/ CPE v2.2 and to facilitate interoperability with v2.2 conformant SCAP tools and content • We define a new formatted string binding for use by CPE v2.3 conformant SCAP tools and content

  5. Naming Specification Scope • In scope: • The logical structure of Well-Formed CPE Names • Procedures for binding well-formed names to their encodings for exchange among machines • Procedures for translating between bindings • Out of scope: • Criteria for determining “correct” or “valid” values for attributes of products • Procedures for comparing/matching names

  6. Well-Formed CPE Names MITRE

  7. Well-Formed CPE Names • A well-formed CPE name (WFN) is an unordered set of attribute-value pairs • Must satisfy these criteria: • Attributes selected from a fixed vocabulary • Each attribute appears at most once in a name • Values of attributes are character strings • Some reserved and special characters • Some attributes may have specified valid values, for most others we recommended that values be chosen from valid-values lists

  8. WFNs: Conceptual Data Structures • WFN is a conceptual data structure • A kind of “normal form” for product identifiers and identifying expressions • There shall be no requirement that SCAP tools use WFNs internally • When discussing WFNs in the spec, we will use the following written representation: • [a1=“v1”,a2=“v2”,…] • Ex1: [part=“a”,vendor=“adobe”,…] • Ex2: [part=“o”,version=“3.*”]

  9. WFNs: Legal Attributes (1/2) • Shall be no mandatory/optional distinction • All attributes are effectively optional • All seven v2.2 components become allowed attributes of WFNs in 2.3: • Part, Vendor, Product, Version, Update, Edition and Language • These will have the same meanings in v2.3 as in v2.2 • NB: the edition attribute will be deprecated in v2.3—its use allowed only under certain circumstances

  10. WFNs: Legal Attributes (2/2) • WFNs shall allow four new legal attributes: • sw_edition (“software edition”) • target_sw (“target software platform”) • target_hw (“target hardware platform”) • other_edition (“other edition data not included elsewhere”) • We will not convert legacy dictionary content to use these new attributes • If any of these four attributes are used in a WFN, the (deprecated) edition attribute must not be used

  11. WFNs: Attribute Values • Attributes values are character strings • US-ASCII character set • Excluding whitespace and CTRL characters • We will specify a maximum string length • Reserved characters: • colon (:), fwd_slash (/), double-quote • These must be percent-encoded when embedded in value strings • Special characters: • Question-mark (?), asterisk (*)

  12. WFNs are Referring Expressions • A WFN is a kind of referring expression • It denotes something (or set of things) in the world • That which is denoted is called the referent • Determining the referent of a WFN depends on its context of use • Ex: “The president of the US” has different referents depending on temporal context • Upper-stack specifications may define contexts of use in which attribute values have special interpretations

  13. Inventory Context • Inventory context is the context of use in which an asset inventory tool reports lists of names of products believed to be installed within an enterprise • Each WFN on the inventory list is intended to have a single product as its referent, but the inventory tool may only be able to provide a partial description of that product • In this context, a WFN is ambiguous if there is more than one possible referent

  14. Catalog Context • Catalog context is the context of use in which an organization creates an authoritative listing of names of distinct products • Each WFN in the catalog is intended to have a single product as its referent, and is assumed to fully describe that product to the best knowledge of the catalog curator • No requirement that each product in the catalog exists either in the world or in the enterprise’s installed inventory

  15. Applicability Context • Applicability context is the context of use in which two WFNs (a “source” and a “target”) are compared to determine whether the referents of the source and target are disjoint • Both the source and the target may be ambiguous—i.e., have multiple referents in the world • Disjointness is determined by reference to a catalog • The catalog serves as a proxy for the world

  16. Bindings MITRE

  17. Terms • To bind a name means: • Convert a WFN to a machine-readable representation suitable for interchange among SCAP applications • To unbind a name means: • To convert a machine-readable representation of a CPE identifier into a WFN

  18. Overview (1/2) • For interoperability purposes, we will define two alternative bindings for a WFN: • A URI binding for use when exchanging CPE information with CPE 2.2 conformant SCAP tools • A formatted string binding for use when exchanging CPE information with CPE 2.3 conformant SCAP tools

  19. Overview (2/2) • In general, the procedure for translating a CPE 2.2-conformant bound name to a CPE 2.3-conformant bound name takes two steps: • First unbind the name into a WFN • Bind the resulting WFN to the desired target binding

  20. Binding a WFN to a formatted string (1/2) • The specified binding of WFN shall be a formatted string prefixed with “cpe-2.3:/” • Iterate through WFN attributes in this order: • part, vendor, product, version, update, edition, sw_edition, target_sw, target_hw, other_edition, language • If edition attribute is used, treat as equivalent to sw_edition, and skip target_sw, target_hw, and other_edition; otherwise ignore edition

  21. Binding a WFN to a formatted string (2/2) • Concatenate value strings together, separating each one with a colon: • If the attribute is absent in the WFN, encode its value as ‘*’ • Thus every attribute value appears explicitly in the bound form • TBD: do we need to be able to elide trailing “:*” substrings?

  22. Ex: WFN to formatted string • “Foo Bar for C++ Professional Edition version 1.3 for 32-bit systems” • WFN: [part=“a”,vendor=“foo”,product=“bar_for_c++”,version=“1.3”,update=“-”,sw_edition=“professional”,target_hw=“x32”] • Bound form: • cpe-2.3:/a:foo:bar_for_c++:1.3:-:professional:*:x32:*:* • target_sw, other_edition and language unspecified, bound to wildcards

  23. Unbinding a CPE-2.3 Name • Straightforward process: • Parse out the attribute value strings in order: • Part, vendor, product, version, update, sw_edition, target_sw, target_hw, other_edition, language • No need to bother with percent-encoded characters since attribute value strings are in normal form

  24. Binding a WFN to a URI (1/2) • Step 1: normalize all value strings • Delete each occurrence of the 2.3-defined special characters (‘?’ and ‘*’) • Percent-encode all RFC-3986 “reserved” characters • Step 2: If the edition attribute is not used in the WFN, create a value for it by “packing” the four other edition-related attributes (next two slides)

  25. Packing (1/2) • Initialize the edition attribute of the WFN to be the empty string • Iterate over the four edition-related attributes: • sw_edition, target_sw, target_hw, other_edition • Append to the edition string: • concatenate “-” and the attribute value • If the attribute value is empty or not specified, use “” • NB: the result is a new string, prefixed with a hyphen, in which each edition-related attribute is concatenated in a fixed order separated by hyphens

  26. Packing (2/2): Examples • “…:-professional-winxp-x64-v88:…” (all four) • “…:---x32-:…” (only target HW; three leading hyphens, one trailing) • “…:--winxp-x32-:…” (middle two)

  27. Binding a WFN to a URI (2/2) • Step 3: Populate the URI template: • cpe:/<part>:<vendor>:<product> … etc. • Step 4: Step thru each corresponding attribute in the WFN, retrieving the corresponding attribute-value pair from the input WFN • If the attribute is absent in the WFN, encode it as a blank component value • Step 5 (opt): After the template is fully populated: • From the right-most end, delete trailing colons (“:”) until the first non-colon is reached

  28. Unbinding a 2.2 Name • Step 1: Parse out the seven components • Step 2: Unpack the edition component (next slide) • Step 3: Decode all percent-encoded characters except colon, slash, dquote • Step 4: Delete each occurrence of the 2.3 special characters (“?” and “*”) • Step 5: Replace blank values with “*”

  29. Unpacking • Unpacking performed when unbinding a 2.2 name into a WFN • The “edition” attribute of the 2.2 name is inspected for a leading hyphen, and if present, the four subdelimited values are parsed out into the four 2.3 edition-related attributes • If no leading hyphen is found, the 2.2 edition attribute is simply copied to the (deprecated) 2.3 edition attribute

  30. Example: WFN to URI • WFN: [vendor=“microsoft”,product=“c#”,update=“-”,target_hw=“x64”] • Normalize the strings and pack the edition attribute: [vendor=“microsoft”,product=“c%23”,update=“-”,edition=“---x64”] • URI after step 4: • cpe:/:microsoft:c%23::-:---x64: • URI after step 5: • cpe:/:microsoft:c%23::-:---x64

  31. Conclusion How does this solution address community issues? MITRE

  32. Does this provide a solution to community issues? • No prefix property—no defined hierarchical relationship among attributes • V2.2 URI binding supported • V2.3 introduces a formatted string binding • V2.3 names may incorporate special characters which may have special meanings • V2.3 names minimize the need for percent encoding • We’ve narrowly scoped the spec to focus on structure and format, leaving meanings and interpretations to upper-stack specs

More Related