draft version 2.1 specification
|
| 1 2 |
|
I have tried to roll up many of the suggestions made via the discussion
list over the past 2 months. Attached is a draft of version 2.1. Note that this would be a minor change and would not affect the structure used to create CPE Names. Below is a list of things included in 2.1 - added Part identifiers for: * Runtime Environments * Libraries * Drivers * Virtual Environments - added Reporting use case - clarified how to handle the Vendor Component when multiple DNS names are registered - clarified how to determine the Product Component (used most common recognizable name) - fixed Microsoft Windows examples - fixed bug in "namePattern" in schemas - allowed multiple "title" elements in dictionary schema If you have additional comments or suggestions, please forward them onto the list. Thanks Drew --------- Andrew Buttner The MITRE Corporation [hidden email] 781-271-3515 |
||||||||
|
|
||||||||
|
|
Yes, here are draft copies of the schema files that have the small
changes outlined in the draft 2.1 spec. One question, I noticed that the namespaces used are: http://cpe.mitre.org/language/2.0 http://cpe.mitre.org/dictionary/2.0 I'm drawing a blank as to if the intention was to change the namespace with each minor release, or if this was an oversight on my part and the namespace should have just ended with '2'. What does everyone think? I know there is some split opinions on this topic in OVAL. Thanks Drew >-----Original Message----- >From: Waltermire, Dave [USA] [mailto:[hidden email]] >Sent: Tuesday, November 06, 2007 6:40 PM >To: cpe-discussion-list CPE Community Forum >Subject: Re: [CPE-DISCUSSION-LIST] draft version 2.1 specification > >Drew, > >Thank you for making these updates. Did you update the 2.0 schemas to >reflect the proper CPE name pattern based on the CPE 2.0 spec? If >this should be done ASAP to correct the defect for organizations that >are currently using CPE 2.0. > >Dave > >> -----Original Message----- >> From: Buttner, Drew [mailto:[hidden email]] >> Sent: Tuesday, November 06, 2007 8:15 AM >> To: [hidden email] >> Subject: [CPE-DISCUSSION-LIST] draft version 2.1 specification >> >> I have tried to roll up many of the suggestions made via the >> discussion list over the past 2 months. Attached is a draft >> of version 2.1. Note that this would be a minor change and >> would not affect the structure used to create CPE Names. >> Below is a list of things included in 2.1 >> >> - added Part identifiers for: >> * Runtime Environments >> * Libraries >> * Drivers >> * Virtual Environments >> - added Reporting use case >> - clarified how to handle the Vendor Component when multiple >> DNS names are registered >> - clarified how to determine the Product Component (used most >> common recognizable name) >> - fixed Microsoft Windows examples >> - fixed bug in "namePattern" in schemas >> - allowed multiple "title" elements in dictionary schema >> >> If you have additional comments or suggestions, please >> forward them onto the list. >> >> Thanks >> Drew >> >> >> --------- >> >> Andrew Buttner >> The MITRE Corporation >> [hidden email] >> 781-271-3515 >> >  cpe-dictionary_2.1_draft.xsd (11K) Download Attachment cpe-language_2.1_draft.xsd (11K) Download Attachment |
||||||||
|
|
||||||||
|
In reply to this post
by Andrew Buttner
|
||||||||
|
In reply to this post
by Andrew Buttner
Drew,
Some minor comments on v2.1. Dave David Lemire Director of Technology and Corporate Capabilties A&N Associates, Inc. 999 Corporate Blvd, Suite 100 Linthicum, Maryland 21090 TEL: 410-859-5449 x111 FAX: 410-859-5292 [hidden email] www.anassoc.com > -----Original Message----- > From: Buttner, Drew [mailto:[hidden email]] > Sent: Tuesday, November 06, 2007 8:15 AM > To: [hidden email] > Subject: [CPE-DISCUSSION-LIST] draft version 2.1 specification > > I have tried to roll up many of the suggestions made via the > discussion list over the past 2 months. Attached is a draft > of version 2.1. Note that this would be a minor change and > would not affect the structure used to create CPE Names. > Below is a list of things included in 2.1 > > - added Part identifiers for: > * Runtime Environments > * Libraries > * Drivers > * Virtual Environments > - added Reporting use case > - clarified how to handle the Vendor Component when multiple > DNS names are registered > - clarified how to determine the Product Component (used most > common recognizable name) > - fixed Microsoft Windows examples > - fixed bug in "namePattern" in schemas > - allowed multiple "title" elements in dictionary schema > > If you have additional comments or suggestions, please > forward them onto the list. > > Thanks > Drew > > > --------- > > Andrew Buttner > The MITRE Corporation > [hidden email] > 781-271-3515 > |
||||||||
|
In reply to this post
by Andrew Buttner
I disagree this fits as a 2.x release. The addition of the new part
identifiers makes the CPE's I'm using obsolete. Seems like that would justify classifying this as a major, versus minor release. I would advocate removing the new part identifiers from this release. I also disagree that adding new part identifiers is necessarily the way to go without having a discussion first. My personal opinion is that it's probably better to talk about the target HW and SW environments for a given application or OS, (or potentially, virtualized hardware) which should accomodate virtualization, macros, drivers, and runtime environments. It does make sense to add a new part for data files which, if used, would result in vulnerabilities. But I think that should be a function of a 3.0 release to come out much later. My suggestions for this minor release: 1. Insert all colons for all CPE parts. This eases the construction of CPE names using a concatenate function when it is automated. 2. Change naming scheme for products that use the nn.nn.nn.nn numbering scheme so that the version field holds the highest order version and the edition or update field holds the complete nn.nn.nn.nn version information. This would allow us to map vulnerabilities at the product-version level and lower level becomes an OVAL problem. 3. Provide implementation guidance for what to do with target SW and HW specifications (e.g. MS Word for MacOSX, or Windows XP 64 bit) 4. Require spelling out of all names versus mandatory abbreviations from an arbitrary list. I'm attaching a list of update names for Microsoft products. I think it's clear from just this list that the abbreviation problem will become unmanageable in the near future if we attempt to keep up with vendor abbreviations. I also can't explain what some of the abbreviations mean, which means humans would have to continually have a copy of the abbreviation guide handy. There's also the problem with abbreviation overlap -- e.g. FR=French and FR=Feature Release. Lt Col Joseph L. Wolfkiel Director, Computer Network Defense Research & Technology (CND R&T) Program Management Office NSA/I71 9800 Savage Rd Ste 6767 Ft Meade, MD 20755-6767 Commercial 410-854-5401 DSN 244-5401 Fax 410-854-6700 -----Original Message----- From: Buttner, Drew [mailto:[hidden email]] Sent: Tuesday, November 06, 2007 8:15 AM To: [hidden email] Subject: [CPE-DISCUSSION-LIST] draft version 2.1 specification I have tried to roll up many of the suggestions made via the discussion list over the past 2 months. Attached is a draft of version 2.1. Note that this would be a minor change and would not affect the structure used to create CPE Names. Below is a list of things included in 2.1 - added Part identifiers for: * Runtime Environments * Libraries * Drivers * Virtual Environments - added Reporting use case - clarified how to handle the Vendor Component when multiple DNS names are registered - clarified how to determine the Product Component (used most common recognizable name) - fixed Microsoft Windows examples - fixed bug in "namePattern" in schemas - allowed multiple "title" elements in dictionary schema If you have additional comments or suggestions, please forward them onto the list. Thanks Drew --------- Andrew Buttner The MITRE Corporation [hidden email] 781-271-3515 |
||||||||
|
|
In reply to this post
by Lemire, David
|
||||||||
|
|
In reply to this post
by Harold Booth-2
|
||||||||
|
|
In reply to this post
by Ken Lassesen-3
|
||||||||
|
|
In reply to this post
by Andrew Buttner
|
||||||||
|
|
In reply to this post
by Wolfkiel, Joseph
|
||||||||
|
|
In reply to this post
by Andrew Buttner
|
||||||||
|
|
|
||||||||
|
> > > 1. Insert all colons for all CPE parts. This eases the
When you start dealing with applications, you don't see as many updates,
> > construction > > > of > > CPE names using a concatenate function when it is automated. > > > > Q: Is the CPE more expressive if all colons are included? > > Are implementations easier with having them versus not having > > them? The behavior should be the same regardless of trailing > > colon use. > > > > Response: Not more expressive, just easier to build business > > logic if you're using a database to dynamically create CPE > > names. E.G. I created CPE names for our application > > database by concatenating "cpe://",[part type],":",[vendor > > name],":",[product],":",[version],":",[update],":",[edition]," > > :",[language]. > > When a field was blank, the concatenate statement still put > > in the colons and there isn't a graceful way to delete them > > back off. I'm not sure about how the rest of the community > > is constructing CPE names, but I'm thinking they may come > > across similar problems. > > I wrote a custom SQL function that does this without adding the extra > colons. I don't see a need for them. Any other experiences with this? editions and languages. Making colons optional also has the advantage of being forward compatible with any number of parts that seem to be coming down the pipeline. Vladimir Giszpenc DSCI Contractor Supporting US Army CERDEC S&TCD IAD Tactical Network Protection Branch (732) 532-8959 |
||||||||
|
|
In reply to this post
by Andrew Buttner
That's an easy win. Is making colons optional a good compromise?
Lt Col Joseph L. Wolfkiel Director, Computer Network Defense Research & Technology (CND R&T) Program Management Office NSA/I71 9800 Savage Rd Ste 6767 Ft Meade, MD 20755-6767 Commercial 410-854-5401 DSN 244-5401 Fax 410-854-6700 -----Original Message----- From: Vladimir Giszpenc [mailto:[hidden email]] Sent: Friday, November 16, 2007 12:14 PM To: [hidden email] Subject: Re: [CPE-DISCUSSION-LIST] draft version 2.1 specification > > > 1. Insert all colons for all CPE parts. This eases the > > construction > > > of > > CPE names using a concatenate function when it is automated. > > > > Q: Is the CPE more expressive if all colons are included? > > Are implementations easier with having them versus not having > > them? The behavior should be the same regardless of trailing > > colon use. > > > > Response: Not more expressive, just easier to build business > > logic if you're using a database to dynamically create CPE > > names. E.G. I created CPE names for our application > > database by concatenating "cpe://",[part type],":",[vendor > > name],":",[product],":",[version],":",[update],":",[edition]," > > :",[language]. > > When a field was blank, the concatenate statement still put > > in the colons and there isn't a graceful way to delete them > > back off. I'm not sure about how the rest of the community > > is constructing CPE names, but I'm thinking they may come > > across similar problems. > > I wrote a custom SQL function that does this without adding the extra > colons. I don't see a need for them. Any other experiences with When you start dealing with applications, you don't see as many updates, editions and languages. Making colons optional also has the advantage of being forward compatible with any number of parts that seem to be coming down the pipeline. Vladimir Giszpenc DSCI Contractor Supporting US Army CERDEC S&TCD IAD Tactical Network Protection Branch (732) 532-8959 |
||||||||
|
|
In reply to this post
by Waltermire, Dave [USA]
|
||||||||
|
|
In reply to this post
by Vladimir Giszpenc
Note that the trailing colons are already optional in the spec and should
not be present if a CPE Name only uses some of the first few components. Please refer to the BNF grammar in Appendix A of the spec. Thanks Drew >-----Original Message----- >From: Vladimir Giszpenc [mailto:[hidden email]] >Sent: Friday, November 16, 2007 12:14 PM >To: cpe-discussion-list CPE Community Forum >Subject: Re: [CPE-DISCUSSION-LIST] draft version 2.1 specification > >> > > 1. Insert all colons for all CPE parts. This eases the >> > construction >> > > of >> > CPE names using a concatenate function when it is automated. >> > >> > Q: Is the CPE more expressive if all colons are included? >> > Are implementations easier with having them versus not having >> > them? The behavior should be the same regardless of trailing >> > colon use. >> > >> > Response: Not more expressive, just easier to build business >> > logic if you're using a database to dynamically create CPE >> > names. E.G. I created CPE names for our application >> > database by concatenating "cpe://",[part type],":",[vendor >> > name],":",[product],":",[version],":",[update],":",[edition]," >> > :",[language]. >> > When a field was blank, the concatenate statement still put >> > in the colons and there isn't a graceful way to delete them >> > back off. I'm not sure about how the rest of the community >> > is constructing CPE names, but I'm thinking they may come >> > across similar problems. >> >> I wrote a custom SQL function that does this without adding the extra >> colons. I don't see a need for them. Any other experiences >with this? > >When you start dealing with applications, you don't see as >many updates, >editions and languages. > >Making colons optional also has the advantage of being forward >compatible >with any number of parts that seem to be coming down the pipeline. > >Vladimir Giszpenc >DSCI Contractor Supporting >US Army CERDEC S&TCD IAD Tactical Network Protection Branch >(732) 532-8959 > |
||||||||
|
|
In reply to this post
by Waltermire, Dave [USA]
|
||||||||
|
|
In reply to this post
by Wolfkiel, Joseph
|
||||||||
| Free Embeddable Forum Powered by Nabble | Help |
