Tracker

In the CPE Dictionary specification and schema, we need to document the use of the deprecated attributes.  We also need to state that one should just ignore the 'deprecated_by' and 'deprecated_date' attributes unless 'deprecated' is set to TRUE.

n/a

Matching within the version component has been a trouble spot for CPE.  Since a CPE Name only has a single component that holds both the major and minor versions (and any other parts to the version), there currently is no way to perform matching at different levels of specificity within the version.  For example, the current matching algorithm does not work between cpe:/a:vendor:product:4.5 and  cpe:/a:vendor:product:4.

Date Added: 2010-04-16 11:27:14
In v2.3 we are working to add support for embedded wildcard characters in CPE names used during matching.  This would allow users to express the idea of, e.g., version "4.*".

Clarification is needed for situations when there is no DNS name affiliated with a certain vendor but an os, application, etc from this vendor is hosted elsewhere.  What is the correct naming methodology for the vendor component?  For example, the vendor Best Software may not have a qualified DNS name yet their application ABC123 may be hosted on an open source software site. It has been proposed that the following paragraph gets added to the Vendor Component section: "In some cases, especially with open source software, a vendor may not have a qualified DNS name. For these situations, the term used in the vendor component should be formed using the most widely known form of the vendor name, replacing spaces with underscores.  For example, the vendor Best Software may not have a qualified DNS name, so a CPE Name for their application ABC123 would be cpe:/a:best_software:abc123".

Date Added: 2009-02-18 01:12:20
The proposed paragraph was added to the vendor component section.

Date Added: 2010-04-16 11:30:34
Reopened for consideration in v2.3

Tim Keanini [tkeanini@NCIRCLE.COM] documents the concern as follows:

At the previous SCAP Developer Days meeting, I raised the issue that the 'Percent Encoding' as defined in the CPE standard version 2.2 section 5.4 is problematic and should be a concern for most implementations. [...] While the RFCs describing the syntax of URI's (rfc3986, rfc2396, rfc2141, rfc1738) are clear on URI characters and escape sequences, the general practice of escaping should be the exception and never the rule.  We in the CPE standard have made it the rule having complete knowledge that there will be a large set of reserved characters that must be escaped.  The CPE standard version 2.2 section 5.1 begins with the sentence "A CPE Name is a percent-encoded URI…".   RFC3986 goes into more details around security considerations in section 7 (Security Considerations) and I feel that as a standard within the Security Automation Content Protocol, we should choose designs that avoid the need to encode/decode in the identifier itself; keeping the non-legal metadata OUT of the identifier and in what is being indentified.
 
Please let me offer two examples: one general and one specific; both pointing to the plethora of unforeseen problems related to percent encoding within the URI.
 
First example: In this general example we show how ambiguity in the URI's alternative transcription should be a concern and avoided as it is dependent on implementation specific encoding and decoding of the URI. There is recognition in the CPE 2.2 specification of this problem to some degree in the sentence "The percent-encoding mechanism is a frequent source of variance among otherwise identical URIs".  And where there is variance in deterministic behavior, there is fertile ground for security related issues:
http://www.technicalinfo.net/papers/URLEmbeddedAttacks.html
http://capec.mitre.org/data/definitions/64.html
http://www.dracos.co.uk/code/apache-rewrite-problem/
One only needs to search for terms like "Percent Encoding Problems" to see scope of the problem.
If we offer up an identifier that does NOT require percent encoding, we side step this problem and can relate metadata to this ID with forms that are not URI's.
 
Second example: Back in March of 2009, I was building a domain ontology using CPE names as an authoritative way to reference a platform.  The promise of a CPE Name in this context is very similar to that of SCAP:  in a universe of Linked Data, one could use this as a "key" to compute the equivalence.  To do this, the CPE Name would have to be used in RDF and more specifically, be successfully translated to and from RDF/XML.  As Jeremy Carroll (an expert in W3C Semantic Technology) points out in my threaded discussion, the syntax allowed by the CPE specification is problematic to the semantic web qname convention and as such will be a problem for RDF libraries.  The discussion can be seen here.
http://groups.google.com/group/topbraid-users/browse_thread/thread/81ed88db9df55ec4/deb88b8d1703122d?lnk=gst&q=CPE&fwc=1 
While each tool may be able to find workarounds, we should not favor designs that require workarounds.

n/a

In the v2.2 dictionary, the edition component has become a dumping ground for three kinds of product information: information about the target hardware (e.g., 32-bit, 64-bit, sparc, etc.), information about the target software (e.g., windows, linux, solaris, oracle), and true information about the software edition (e.g., "home edition", "professional edition", "personal edition").  These items have been inconsistently recorded in the 2.2 edition field.  In a future version of the CPE standard, we'd like to pull those distinct items of information out and record them separately.

As of this writing, we are likely deferring this to v3.0.

Date Added: 2010-04-22 17:57:08
Seth Hanford (shanford@cisco.com)writes: Is the "edition" component the appropriate location for hardware architecture? For example:
cpe:/o:redhat:enterprise_linux:2.1::ia64-as

This specifies architecture and edition in conjunction; I believe it might
be beneficial to separate the edition components (enterprise_linux:::as)
from the architecture (enterprise_linux:::::ia64) so that each could be used
as a qualifier for affected software independent of the other (e.g.
Vulnerabilities affecting all AS products, or flaws specific to the ia64
architecture across all editions).  FreeNAS uses edition for architecture exclusively:
cpe:/o:freenas:freenas:0.69.1:-:amd64

We need a mechanism for dealing with the real-world changes that occur over time, for example, when vendors merge or change their brand names, and when product names change.

Date Added: 2010-04-22 18:03:19
Seth Hanford (shanford@cisco.com) writes: Would there be any way to carry [ordering of product releases] mapping across product names / vendors?
If I recall correctly, iPlanet 4.0 was acquired and became Sun iPlanet 4.1,
then Sun ONE Web Server 5, then Sun Java System Web Server 6 and 7.  Iplanet
and Sun ONE would both be candidates for "previous" in relation to Sun Java
System Web Server 7.  This issue also relates to representing ordering relations in general among products.

[Robert L. Hollis @ 5/27/2010]: In most CPE discussions I've observed at various developer days, there seems to have been a consensus that the CPE Name must *not* carry self-defining information.  I apologize for missing recent logic that counters that point, however I think that it was a good basic premise.

That said, I'm in complete agreement that there needs to be a well-known way
to determine a CPE name from field data (like vendor, product name,
version).

I think this could be accomplished as follows:

1) Provide a web-service that generates new CPE IDs
2) Use vendor/product/version strings that are returned by local software
tracking repositories (registry keys, RPM, swdepot, pkg, etc.)
3) Publish the CPE Dictionary *with* a built-in look-up table
	-- or --
3) Use the natural hierarchical structure of XML for the dictionary.

Re: the CPE IDs
I like the MAC address approach.  Have a manufacturer segment, product
segment, and version segment.  Perhaps something like this...

	CPE-1093-1010-1003

A couple things to note:
1) fixed length
2) arbitrary, yet sequential segment values


From here if we used a hierarchical look-up table, it could be structured
something like this:
<cpe-lookup>
    <vendor name="vendor-a" id="1001">
        <product name="super product x" id="1001">
            <alias>nickname 1</alias>
            <alias>nickname 2</alias>
            <alias>nickname 3</alias>
            <version name="1.0" id="1001"/>
            <version name="2.1" id="1002"/>
            <version name="3.0" id="1003"/>
        </product>
        <product name="legacy product l" id="1002">
            <alias>nickname 1</alias>
            <alias>nickname 2</alias>
            <version name="5.1" id="1001"/>
            <version name="5.1.5" id="1002"/>
        </product>
        <product name="beta product b" id="1003">
            <version name="1.0" id="1001"/>
            <version name="2.1" id="1002"/>
        </product>
    </vendor>
</cpe-lookup>

NOTE: vendor, product, etc. names are deliberately *not* mixed case.  If
various interrogation techniques return different strings, use the <alias/>
elements to capture alternatives.

With this, it would be simple to look up vendor-a's legacy product 1,
version 5.1.5 to be

	CPE-1001-1002-1002

And if you're working with an alias, or part of an alias for the product,
you can programmatically run regex comparisons on a vendor's product names
and respective aliases to get a list of matching CPE IDs.  Like, "vendor-a's
nickname 2, version 5.1*" would yield

	CPE-1001-1002-1001
	CPE-1001-1002-1002

Re: drop the current flat structure of the dictionary an go hierarchical

As I consider the look-up table above, I start to wonder why we would need a
flat structure at all.  If that look-up table was *the* dictionary, it would
be pretty simple to construct an XPath query from the CPE ID, and straight
forward to find matching IDs from field data.  Furthermore, the
product/version does not need to be exact to have a reasonable chance of
determining the CPE ID (or a set of matching CPE IDs).  The key would be
using names (and aliases) that match the strings our products would receive
on interrogation.

n/a