If spending our time doing incremental updates to CPE 2.x is the best option for the April meeting, then I'll support that.
However, some of the things that keep tripping us up are fundamental concepts in CPE 2.x such as the omnipotent URI format, lack of tolerance for aliasing, the inability to do matching within components, and the inability to gracefully deal with component names that can be associated with multiple other higher-level component names.
My vision was to design a 3.0 version that could re-use all the content from 2.x, but better deal with the limitations. I think we can tweak 2.x to deal with some of the issues (and have, within the DoD data strategy pilot confines), but there are limitations on what you can do with the concept of "item" and "platform" as all-purpose text strings.
I'll see everyone at the April meeting.
Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program Management Office
9800 Savage Rd Ste 6767
From: Kent Landfield [mailto:[hidden email]]
Sent: Thursday, March 20, 2008 3:26 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Informal Meeting at RSA
Wow… very old data… A word count on The Official NVD CPE Dictionary is
2661 7586 133511 cpe-dictionary-2.0.xml
And has only 839 CPE entries from two vendors.
What you are looking at was the NVD dictionary before CPE 2.0 was adopted.
The NVD CPE list includes around 5500 vendors, over 20,000 releases.
The existing list has approximately 5% duplicate entries, where it seems that one NVD collector created one name and entry, and another created a different vendor name.
The CPE needs a meta-layer, allowing name aliases for vendors, applications, releases. The aliases would allow both private and public alias for existing names. In this way, a vendor can map a proprietary naming scheme into the CPE using the alias table, without breaking his software or requiring the CPE to change.
The dictionary benefits when it is public, searchable, and can be synchronized among users in some fashion.
I believe that authoritative data can come from a number of sources. My staff researches this information daily, and can provide valuable information on an ongoing basis. If more of our professional community can rate their expertise to deliver this information, we can build a community created and edited dictionary of very reliable information, a definitive index of names and identifiers of those millions of electronic assets that we all work with.
What the dictionary needs is a member forum for immediately growing and editing the dictionary, and an alias framework to allow working through the duplicates and the naming irregularities.
On 3/20/08, Waltermire, Dave [
The only authoritative data we have is from Apple and RedHat as you have indicated. Any names beyond this are for products that we have had in the NVD that we are adding to the dictionary.
Great thread, it is always positive when so much of the community comes
together in a discussion. I will try to throw my thoughts into this
and add a little history as well. (I hope I have the history correct)
I personally think the 2.x spec is very solid and meets the goals we
set out to accomplish. Having said that, it obviously can not be used,
or meet its goals, without a robust dictionary of official names. We
have seen the importance of the dictionary in CVE, as well as the
reliance on such for the progress of CCE. The biggest need for CPE
right now is the dictionary.
The idea behind the 3.0 discussion was focused on requests that have
been made to MITRE and what we perceived as a call for the next
version. CPE 2.0 was released on 9/14/08. (Yes, the release was a
little rushed to meet requests from SCAP, but it also followed over 2
months of work with a first draft on 7/20/08) My thinking was that if
we discuss possible changes in the spring, we wouldn't have a release
until fall, meaning that 2.x would have been out there for a full year.
Given the amount and urgency of requests that were made, I was ok with
this time frame.
I think both Neal and I have been adamant about giving 2.x a chance. If
the community wants to continue with 2.x, we obviously would more than
happy to follow this course. Again, I really think 2.x is solid and
workable. Of course we NEED a dictionary to make this happen.
Going forward ... I will continue to do what I can to help bring a
working dictionary to CPE. I will also work on a new version of the
agenda for our meeting April 30th.
Please do not consider this thread closed. The more opinions that are
expressed the better.
> I personally think the 2.x spec is very solid and meets the goals we
> set out to accomplish. Having said that, it obviously can not be used,
It seems that huge changes are off the table and that is fine, but I think
we should identify things we can do now to make migration to a 3.0
specification later as easy as possible.
> However, some of the things that keep tripping us up are fundamental
> concepts in CPE 2.x such as the omnipotent URI format, lack of tolerance
> for aliasing, the inability to do matching within components, and the
> inability to gracefully deal with component names that can be associated
> with multiple other higher-level component names.
Are these issues barriers to adoption? In other words, are they the reason
we are not getting new CPEs in mass?
> Come on. Sigh. Sorry, take 'commercial' out of my statement and it covers
> open source as well. I was trying to differentiate it from only a federal
> government GOTS focus. This is a community standard as you so accurately
As a GOTS producer I take offense :). Seriously, we all need stability,
COTS, GOTS, open source, commercial and all. I think that we should strive
to make the current standard as forward compatible (i.e. extensible e.g. add
aliasing) as possible.
My 2 cents (worth less and less each day)
Have a nice weekend and take nice notes at RSA!
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
smime.p7s (4K) Download Attachment
|Free forum by Nabble||Edit this page|