Ambiguity assigning CPE name to product - help please

[Whyman, Paul Arthur]

Hello all,

I have been trying to assign a CPE name to a particularly troublesome application, I wonder if someone can provide assistance.

The culprit is a package called libuuid1 1.39+1.40-WIP-2006.11.14+dfsg-2ubuntu1.1 from Ubuntu Feisty

More information can be found here: http://packages.ubuntu.com/feisty/libs/libuuid1

Here are the ambiguous parts of the metadata:

Part: application
Vendor: e2fsprogs -or- Debian -or- Ubuntu -and- what to do with feisty ?
Product: libuuid1
Version -?- Update -?- Edition: 1.39+1.40-WIP-2006.11.14+dfsg-2ubuntu1.1
Language: English


The goal is to be able to map this file back to the entry in the NVD which indicates e2fsprogs has a vulnerability and determine if this version is vulnerable. See http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5497

Suggestions?

--
Paul Whyman
Open Source & Linux Organization R&D (OSLO)
Hewlett Packard Company

[Wolfkiel, Joseph]

I'd say the cop-out answer is to just use an update of the cpe name the NVD
shows for the product.  From the CVE entry, it looks like NVD mapped it to:
cpe:///ext2_filesystems_utilities:e2fsprogs, which would directly translate
to "cpe:/a:ext2_filesystems_utilities:e2fsprogs" in the new CPE spec.

This name will directly map (text match) to the "right" index in the NVD to
get you the correct vulnerabilities against the specific platform.

Doing the cop-out saves you from dealing with the multiple vendor problem
and figuring out how to deal with the "+" characters which aren't allowed in
the cpe namePattern type.  If you want to put the
"1.39+1.40-WIP-2006.11.14+dfsg-2ubuntu1.1" text somewhere, I'd recommend the
version field for the sole reason that it's the place where we already have
similar problems dealing with the nnn.nnn.nnn.xyz(abc)+qrs types of version
names already out there (e.g. Cisco).

Lt Col Joseph L. Wolfkiel

Director, Computer Network Defense Research & Technology (CND R&T) Program
Management Office

9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax [phone]


-----Original Message-----
From: Whyman, Paul Arthur [mailto:[hidden email]]
Sent: Thursday, January 24, 2008 6:10 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Ambiguity assigning CPE name to product -
help please


Hello all,

I have been trying to assign a CPE name to a particularly troublesome
application, I wonder if someone can provide assistance.

The culprit is a package called libuuid1
1.39+1.40-WIP-2006.11.14+dfsg-2ubuntu1.1 from Ubuntu Feisty

More information can be found here:
http://packages.ubuntu.com/feisty/libs/libuuid1

Here are the ambiguous parts of the metadata:

Part: application
Vendor: e2fsprogs -or- Debian -or- Ubuntu -and- what to do with feisty ?
Product: libuuid1
Version -?- Update -?- Edition: 1.39+1.40-WIP-2006.11.14+dfsg-2ubuntu1.1
Language: English


The goal is to be able to map this file back to the entry in the NVD which
indicates e2fsprogs has a vulnerability and determine if this version is
vulnerable. See http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5497

Suggestions?

--
Paul Whyman
Open Source & Linux Organization R&D (OSLO)
Hewlett Packard Company

[Andrew Buttner]

I think this is a great example to work through as a community as this
should help answer many questions about future packages we try to name.

Note the 2.1 name format is:

cpe:/ {part} :
      {vendor} :
      {product} :
      {version} :
      {update} :
      {edition} :
      {language}

In the example you bring up below, you are correct that the part would
be 'application'. I'd say the vendor is 'Ubuntu' as this is who built
the package. I'd say the product = 'libuuid1' as this is the name of
the specific package in question.  My first guess would be to use
'1.39+1.40-WIP-2006.11.14+dfsg-2ubuntu1.1' as the version component.
So I'd quickly say that the CPE Name would be:

cpe:/a:ubuntu:libuuid1:1.39+1.40-WIP-2006.11.14+dfsg-2ubuntu1.1

Lt Col Wolfkiel is correct that the "+" character is a URI reserved
char not allowed in a CPE Name.  How should we handle this?

* just remove the character, so the version would become
1.391.40-WIP-2006.11.14dfsg-2ubuntu1.1

* create a special char code for it.  Maybe 'p' or '-p-' or '-pl-' or
'--p--' or ...?  The version would become
1.39--p--1.40-WIP-2006.11.14--p--dfsg-2ubuntu1.1  We could make similar
char codes for things like greater than '-gt-' so we could name
platform types with a version greater than something.  thoughts?

It seems that 'Feisty' and 'e2fsprogs' are names given to different
package bundle (that includes libuuid1).  I don't think that 'Feisty'
or 'e2fsprogs' would be in the CPE Name.  It would be possible though
that we could have a different CPE Name for Feisty
(cpe:/a:ubuntu:feisty) or e2fsprogs (cpe:/a:ubuntu:e2fsprogs) if we
wanted to name a platform type that includes these packages.  Make
sense?

I'd be very interested in how others think about this example.

Thanks
Drew

>-----Original Message-----
>From: Whyman, Paul Arthur [mailto:[hidden email]]
>Sent: Thursday, January 24, 2008 6:10 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: [CPE-DISCUSSION-LIST] Ambiguity assigning CPE name to
>product - help please
>
>Hello all,
>
>I have been trying to assign a CPE name to a particularly
>troublesome application, I wonder if someone can provide assistance.
>
>The culprit is a package called libuuid1
>1.39+1.40-WIP-2006.11.14+dfsg-2ubuntu1.1 from Ubuntu Feisty
>
>More information can be found here:
>http://packages.ubuntu.com/feisty/libs/libuuid1
>
>Here are the ambiguous parts of the metadata:
>
>Part: application
>Vendor: e2fsprogs -or- Debian -or- Ubuntu -and- what to do
>with feisty ?
>Product: libuuid1
>Version -?- Update -?- Edition:
>1.39+1.40-WIP-2006.11.14+dfsg-2ubuntu1.1
>Language: English
>
>
>The goal is to be able to map this file back to the entry in
>the NVD which indicates e2fsprogs has a vulnerability and
>determine if this version is vulnerable. See
>http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5497
>
>Suggestions?
>
>--
>Paul Whyman
>Open Source & Linux Organization R&D (OSLO)
>Hewlett Packard Company
>

[Thomas R. Jones]

Sent from my iPhone

On Jan 25, 2008, at 7:04 AM, "Buttner, Drew" <[hidden email]> wrote:

> I think this is a great example to work through as a community as this
> should help answer many questions about future packages we try to  
> name.
>
> Note the 2.1 name format is:
>
> cpe:/ {part} :
>      {vendor} :
>      {product} :
>      {version} :
>      {update} :
>      {edition} :
>      {language}
>
> In the example you bring up below, you are correct that the part would
> be 'application'. I'd say the vendor is 'Ubuntu' as this is who built
> the package. I'd say the product = 'libuuid1' as this is the name of
> the specific package in question.  My first guess would be to use
> '1.39+1.40-WIP-2006.11.14+dfsg-2ubuntu1.1' as the version component.
> So I'd quickly say that the CPE Name would be:
>
> cpe:/a:ubuntu:libuuid1:1.39+1.40-WIP-2006.11.14+dfsg-2ubuntu1.1
>
> Lt Col Wolfkiel is correct that the "+" character is a URI reserved
> char not allowed in a CPE Name.  How should we handle this?
>
> * just remove the character, so the version would become
> 1.391.40-WIP-2006.11.14dfsg-2ubuntu1.1
>
> * create a special char code for it.  Maybe 'p' or '-p-' or '-pl-' or
> '--p--' or ...?  The version would become
> 1.39--p--1.40-WIP-2006.11.14--p--dfsg-2ubuntu1.1  We could make  
> similar
> char codes for things like greater than '-gt-' so we could name
> platform types with a version greater than something.  thoughts?
>
> It seems that 'Feisty' and 'e2fsprogs' are names given to different
> package bundle (that includes libuuid1).  I don't think that 'Feisty'
> or 'e2fsprogs' would be in the CPE Name.  It would be possible though
> that we could have a different CPE Name for Feisty
> (cpe:/a:ubuntu:feisty) or e2fsprogs (cpe:/a:ubuntu:e2fsprogs) if we
> wanted to name a platform type that includes these packages.  Make
> sense?

Feisty is the development name of the 7.04 release of the ubuntu  
distribution.

>
>
> I'd be very interested in how others think about this example.
>
> Thanks
> Drew
>
>
>> -----Original Message-----
>> From: Whyman, Paul Arthur [mailto:[hidden email]]
>> Sent: Thursday, January 24, 2008 6:10 PM
>> To: cpe-discussion-list CPE Community Forum
>> Subject: [CPE-DISCUSSION-LIST] Ambiguity assigning CPE name to
>> product - help please
>>
>> Hello all,
>>
>> I have been trying to assign a CPE name to a particularly
>> troublesome application, I wonder if someone can provide assistance.
>>
>> The culprit is a package called libuuid1
>> 1.39+1.40-WIP-2006.11.14+dfsg-2ubuntu1.1 from Ubuntu Feisty
>>
>> More information can be found here:
>> http://packages.ubuntu.com/feisty/libs/libuuid1
>>
>> Here are the ambiguous parts of the metadata:
>>
>> Part: application
>> Vendor: e2fsprogs -or- Debian -or- Ubuntu -and- what to do
>> with feisty ?
>> Product: libuuid1
>> Version -?- Update -?- Edition:
>> 1.39+1.40-WIP-2006.11.14+dfsg-2ubuntu1.1
>> Language: English
>>
>>
>> The goal is to be able to map this file back to the entry in
>> the NVD which indicates e2fsprogs has a vulnerability and
>> determine if this version is vulnerable. See
>> http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5497
>>
>> Suggestions?
>>
>> --
>> Paul Whyman
>> Open Source & Linux Organization R&D (OSLO)
>> Hewlett Packard Company
>>

[Andrew Buttner]

>Feisty is the development name of the 7.04 release of the ubuntu  
>distribution.

So for CPE Names for the Ubuntu OS, would we have:

cpe:/o:ubuntu:ubuntu:feisty

as opposed to:

cpe:/o:ubuntu:ubuntu:7.04

[Mark J Cox-2]

> I'd say the vendor is 'Ubuntu' as this is who built
> the package.

I'd agree; in this case it's clear that Ubuntu have taken the upstream
version of 1.39 from the project, added in some stuff that is pre-release
from the upstream project, added in more stuff themselves, and released
the result.  This happens a lot with linux distributions, particularly
those that do things like backports of security patches to stable
versions.

Where it is perhaps less clear are things that vendors like Red Hat
package for add-on distribution channels; like acrobat reader.  These
things are binary-only so Red Hat hasn't made any changes to the code, so
you could argue it's the same thing as you'd get from Adbobe and should be
vendor=adobe.  Although we repackage it from a tar.gz file into rpm.  To
extend this argument what about bundles?  If acrobat reader is bundled
with XP SP2 is it vendor=microsoft or vendor=adobe?

Thanks, Mark
--
Mark J Cox / Red Hat Security Response Team

[Waltermire, Dave [USA]]

> Lt Col Wolfkiel is correct that the "+" character is a URI
> reserved char not allowed in a CPE Name.  How should we handle this?
>
> * just remove the character, so the version would become
> 1.391.40-WIP-2006.11.14dfsg-2ubuntu1.1
>
> * create a special char code for it.  Maybe 'p' or '-p-' or
> '-pl-' or '--p--' or ...?  The version would become
> 1.39--p--1.40-WIP-2006.11.14--p--dfsg-2ubuntu1.1  We could
> make similar char codes for things like greater than '-gt-'
> so we could name platform types with a version greater than
> something.  thoughts?

Why are we reinventing the wheel here?  URIs allow URL encoding to be
used for URI reserved characters.  If you need a plus you can use the
code: %2b.  The advantage of this approach is that in most cases we can
use standard URI handling routines to escape/unescape the text
converting a URI to and from a string representation.  This seems like a
much more standards based solution.

Dave

[Ken Lassesen-3]

I agree with Dave, use the %2b.  

Also, I believe that Feisty is for 7.xx and not just 7.04 (which is
Feisty Fawn),

Ken Lassesen,
Office 206-734-4718 Home: 360-724-3190
Cell: 360-509-2402  Skype: Ken.Lassesen
IM: [hidden email]   http://www.linkedin.com/in/lassesen 
CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain
confidential and privileged information and is intended only for use by
the individual(s) or entity(ies) to whom it was addressed. Any
unauthorized review, use, disclosure, or distribution of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.


-----Original Message-----
From: Waltermire, Dave [USA] [mailto:[hidden email]]
Sent: Friday, January 25, 2008 7:31 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Ambiguity assigning CPE name to
product - help please

> Lt Col Wolfkiel is correct that the "+" character is a URI reserved
> char not allowed in a CPE Name.  How should we handle this?
>
> * just remove the character, so the version would become
> 1.391.40-WIP-2006.11.14dfsg-2ubuntu1.1
>
> * create a special char code for it.  Maybe 'p' or '-p-' or '-pl-' or
> '--p--' or ...?  The version would become
> 1.39--p--1.40-WIP-2006.11.14--p--dfsg-2ubuntu1.1  We could make
> similar char codes for things like greater than '-gt-'
> so we could name platform types with a version greater than something.

> thoughts?

Why are we reinventing the wheel here?  URIs allow URL encoding to be
used for URI reserved characters.  If you need a plus you can use the
code: %2b.  The advantage of this approach is that in most cases we can
use standard URI handling routines to escape/unescape the text
converting a URI to and from a string representation.  This seems like a
much more standards based solution.

Dave

[Thomas R. Jones]

Actually, I believe it should be:
cpe:/o:canonical:ubuntu:feisty

Canonical ltd. Is the registered trademark owner of the ubuntu  
distribution.

Sent from my iPhone

On Jan 25, 2008, at 8:46 AM, "Buttner, Drew" <[hidden email]> wrote:

>> Feisty is the development name of the 7.04 release of the ubuntu
>> distribution.
>
> So for CPE Names for the Ubuntu OS, would we have:
>
> cpe:/o:ubuntu:ubuntu:feisty
>
> as opposed to:
>
> cpe:/o:ubuntu:ubuntu:7.04

[Andrew Buttner]

>Where it is perhaps less clear are things that vendors like Red Hat
>package for add-on distribution channels; like acrobat reader.  These
>things are binary-only so Red Hat hasn't made any changes to
>the code, so you could argue it's the same thing as you'd get from
>Adbobe and should be vendor=adobe.  Although we repackage it from a
>tar.gz file into rpm.  To extend this argument what about bundles?
>If acrobat reader is bundled with XP SP2 is it vendor=microsoft or
>vendor=adobe?

I'd answer this question with the following ... if a vendor just
bundles the binary they receive from another vendor, than that package
would be known by the original vendor.  But they new vendor modifies
the package, re-builds the package, etc, then we would use the new
vendor.  Another way of thinking about this is if we would ever want to
make a distinction between what comes from the original vendor and what
is packaged by the new vendor, then we would want separate names.

I think this is something that right now will be a bit of a case by
case basis until we learn more about possible rules to apply during the
naming.

Thanks
Drew

[Andrew Buttner]

>Actually, I believe it should be:
>cpe:/o:canonical:ubuntu:feisty
>
>Canonical ltd. Is the registered trademark owner of the ubuntu  
>distribution.

agree, thanks for pointing this out.

[Andrew Buttner]

>> Lt Col Wolfkiel is correct that the "+" character is a URI
>> reserved char not allowed in a CPE Name.  How should we handle this?
>>
>> * just remove the character, so the version would become
>> 1.391.40-WIP-2006.11.14dfsg-2ubuntu1.1
>>
>> * create a special char code for it.  Maybe 'p' or '-p-' or
>> '-pl-' or '--p--' or ...?  The version would become
>> 1.39--p--1.40-WIP-2006.11.14--p--dfsg-2ubuntu1.1  We could
>> make similar char codes for things like greater than '-gt-'
>> so we could name platform types with a version greater than
>> something.  thoughts?
>
>Why are we reinventing the wheel here?  URIs allow URL encoding to be
>used for URI reserved characters.  If you need a plus you can use the
>code: %2b.  The advantage of this approach is that in most cases we

can
>use standard URI handling routines to escape/unescape the text
>converting a URI to and from a string representation.  This
>seems like a
>much more standards based solution.


Great point Dave.  This makes sense to me.

Thanks
Drew

[Whyman, Paul Arthur]

This discussion is great, it is very helpful and I appreciate the number and quality of the responses. Thanks.

To add clarity to the continued discussion, here is some additional information regarding the version string.

The source is derived from three places:
1) upstream http://e2fsprogs.sourceforge.net
2) Debian http://packages.debian.org/sid/libuuid1
3) Ubuntu http://packages.ubuntu.com/feisty/libs/libuuid1 the final packager

Feisty is to Ubuntu almost as Windows XP is to Microsoft (the relationships between Ubuntu and Windows are not exact to be sure). Retaining information that the package is part of Ubuntu Feisty is good to retain. The package origin, the e2fsprogs project, is good to retain in the CPE name for identification and tracking, I like that this was done by the CVE.

Deciphering 1.39+1.40-WIP-2006.11.14+dfsg-2ubuntu1.1 we find:

1.39
   Source Maintainers Release Version (also called upstream version)
+ 1.40-WIP-2006.11.14
   Some bits were added from an upcoming upstream release candidate as of January Fourteenth 2006
+ dfsg
   changes were applied to comply with the Debian Free Software Guidelines
+ 2
   Second update by the Debian Package Maintainer
+ ubuntu1
   First update by the Ubuntu Package Maintainer
+ .1
   Something was added by Ubuntu, the decimal indicates the work was not done by the official maintainer. This is often the case with security patches which, as in this example, can be applied by a member of the security team.


The realization which interests me is that this package is not vulnerable; it has had a security fix backported and applied by Ubuntu.

The issue is: How will the CPE name achieve the requirement that "Each CPE Name MUST exhibit the prefix property."? This package is not a direct descendant of any upstream version. It is an amalgamation, creating a package which is unique. Nevertheless, there still is an important relationship as the package was developed upstream, the vulnerability introduced upstream, yet the fix was applied downstream. Who is the vendor?

The CVE vulnerability summary lists versions before 1.40.3 as vulnerable. Yet, how would one determine if the actual package version is less-than-or-equal-to the version listed in the CVE?. The most recent upstream bits listed in the package version string is 1.40 which is less than 1.40.3 listed in the CVE. Without knowing the fix was backported, a match against the CVE version will generate a false positive. In short, how does the CPE handle backports?

One can determine if a package is vulnerable by using the vendors information, in this case Ubuntu. One can check the libuuid1 changelog (which is likely even on the system) and read "...Add checks to prevent integer overflows passed to malloc().  Fixes security issue... CVE-2007-5497" However how will one determine this by only using the NVD using a CPE name?

I look forward to reading your responses, however I will be delayed until I return to the office on Monday the 11th of January. I fell bad for starting this thread and then going on vacation! ...well not *that* bad ;)

Regards, Paul

--
Paul Whyman
Open Source & Linux Organization R&D (OSLO)
Hewlett Packard Company

[Mark J Cox-2]

> The CVE vulnerability summary lists versions before 1.40.3 as
> vulnerable. Yet, how would one determine if the actual package version
> is less-than-or-equal-to the version listed in the CVE?. The most recent
> upstream bits listed in the package version string is 1.40 which is less
> than 1.40.3 listed in the CVE. Without knowing the fix was backported, a
> match against the CVE version will generate a false positive. In short,
> how does the CPE handle backports?

This is why Red Hat publishes our own OVAL repository containing the
information on how to check for CVE corrections in backports; you can't
make decisions about vulnerable versions using just NVD and CPE alone:

Take for example CVE-2007-6388 a flaw in mod_status in Apache HTTP server.
Since there are currently three released and supported versions of Apache
there are three sets of versions that are vulnerable to this issue.  You
can't simply say because this was fixed in 2.2.8 that you're vulnerable if
httpd installed is less than 2.2.8.

You're vulnerable if you have the vendor=Apache Software Foundation
product=Apache HTTP Server with ( 2.2.8 < version <= 2.2.0 ) or
( 2.0.63 < version <= 2.0.0 ) or (1.3.41 < version)

Or... you're vulnerable if you are using Red Hat Enterprise Linux 5 and
have the vendor=Red Hat product=Apache HTTP Server with httpd RPM
(2.2.3-11.el5_1.3 < version)

Or... you're vulnerable if you are using Red Hat Enterprise Linux 2.1 and
have the vendor=Red Hat product=Apache HTTP Server with apache RPM
(1.3.27-14.ent < version)

Or... you're vulnerable if you are using Mandriva Corporate Server 3.0 and
have the vendor=Mandriva product=Apache HTTP Server with apache RPM
(1.3.29-1.7.C30mdk < version)

and so on; Red Hat alone has five products with different versions of
Apache HTTP Server with different combinations of fixes, then add in
Fedora, I spotted another five or six more for Mandriva, and then there
are all the dozens of other folks that ship Apache HTTP Server in their
products.

Also you can't rely on the version information given by vulnerability
databases (including CVE/NVD) because they're usually based on third party
information that is incomplete, inaccurate, or unable to predict the
future (Entries might state "version 6.4 and earlier are vulnerable" but
that doesn't mean that the issue actually got fixed in
>6.4, this might be an issue that is as yet unfixed at the time of CVE
entry).

Thanks, Mark
--
Mark J Cox / Red Hat Security Response Team

[Andrew Buttner]

>The issue is: How will the CPE name achieve the requirement
>that "Each CPE Name MUST exhibit the prefix property."? This
>package is not a direct descendant of any upstream version. It
>is an amalgamation, creating a package which is unique.
>Nevertheless, there still is an important relationship as the
>package was developed upstream, the vulnerability introduced
>upstream, yet the fix was applied downstream. Who is the vendor?

Building on what Mark Cox said, the goal of CPE is not to encode these
important relationships, but rather to provide a unique identifier for
specific platform types (in this case a specific package).  The prefix
property only refers to the structure of the id such that CPE Matching
can occur.  In short ... if cpe:/a:b:c:d is found to be true, then
cpe:/a:b:c must also be true, and cpe:/a:b must be true, etc.

The other important relationships must be described / stored in other
languages like CVE and/or OVAL.

Thanks
Drew

[Andrew Buttner]

Just realized that % is a prohibited char:

* percent-sign (%) - not permitted because it is used for character
encoding in URIs.

My thought is that we should remove the % as a prohibited character,
but add a section right after the section on "Prohibited Characters"
explaining the character encoding mechanism and how it should be used
to denote any of the prohibited chars.

Prohibiting the % char in the first place was definitely an oversight
on my part.

Thanks
Drew

>-----Original Message-----
>From: Ken Lassesen [mailto:[hidden email]]
>Sent: Friday, January 25, 2008 11:21 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Ambiguity assigning CPE
>name to product - help please
>
>I agree with Dave, use the %2b.  
>
>-----Original Message-----
>From: Waltermire, Dave [USA] [mailto:[hidden email]]
>Sent: Friday, January 25, 2008 7:31 AM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] Ambiguity assigning CPE name to
>product - help please
>
>Why are we reinventing the wheel here?  URIs allow URL encoding to be
>used for URI reserved characters.  If you need a plus you can use the
>code: %2b.  The advantage of this approach is that in most cases we

can
>use standard URI handling routines to escape/unescape the text
>converting a URI to and from a string representation.  This
>seems like a
>much more standards based solution.
>
>Dave
>

[Gary Newman-2]

If the spec is changed to say % isn't prohibited then none of the other URI
prohibited characters should be listed as prohibited.  The spec isn't clear
enough about pre v.s. post URI encoding.

The CPE spec could have a bit more clarity in how the URI encoding process
happens.  This section of the URI spec

        http://gbiv.com/protocols/uri/rfc/rfc3986.html#when-to-percent-encode

covers that process nicely, and could be transcribed into the CPE spec to
clarify.

"Under normal circumstances, the only time when octets within a URI are percent-
encoded is during the process of producing the URI from its component parts.
This is when an implementation determines which of the reserved characters are
to be used as subcomponent delimiters and which can be safely used as data.
Once produced, a URI is always in its percent-encoded form."

        -Gary-

> Just realized that % is a prohibited char:
>
> * percent-sign (%) - not permitted because it is used for character
> encoding in URIs.
>
> My thought is that we should remove the % as a prohibited character,
> but add a section right after the section on "Prohibited Characters"
> explaining the character encoding mechanism and how it should be used
> to denote any of the prohibited chars.
>
> Prohibiting the % char in the first place was definitely an oversight
> on my part.
>
> Thanks
> Drew
>
>
> >-----Original Message-----
> >From: Ken Lassesen [mailto:[hidden email]]
> >Sent: Friday, January 25, 2008 11:21 AM
> >To: cpe-discussion-list CPE Community Forum
> >Subject: Re: [CPE-DISCUSSION-LIST] Ambiguity assigning CPE
> >name to product - help please
> >
> >I agree with Dave, use the %2b.  
> >
> >-----Original Message-----
> >From: Waltermire, Dave [USA] [mailto:[hidden email]]
> >Sent: Friday, January 25, 2008 7:31 AM
> >To: [hidden email]
> >Subject: Re: [CPE-DISCUSSION-LIST] Ambiguity assigning CPE name to
> >product - help please
> >
> >Why are we reinventing the wheel here?  URIs allow URL encoding to be
> >used for URI reserved characters.  If you need a plus you can use the
> >code: %2b.  The advantage of this approach is that in most cases we
> can
> >use standard URI handling routines to escape/unescape the text
> >converting a URI to and from a string representation.  This
> >seems like a
> >much more standards based solution.
> >
> >Dave
> >
>
>
>

[Ken Lassesen-3]

But Drew this is exactly how it is being used, it is being used for
character encoding in URIs!  We are not putting a '%' in the string, we
are putting the encoding in the string


Ken Lassesen,
Office 206-734-4718 Home: 360-724-3190
Cell: 360-509-2402  Skype: Ken.Lassesen
IM: [hidden email]   http://www.linkedin.com/in/lassesen 
CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain
confidential and privileged information and is intended only for use by
the individual(s) or entity(ies) to whom it was addressed. Any
unauthorized review, use, disclosure, or distribution of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.


-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Monday, January 28, 2008 7:17 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Ambiguity assigning CPE name to
product - help please

Just realized that % is a prohibited char:

* percent-sign (%) - not permitted because it is used for character
encoding in URIs.

My thought is that we should remove the % as a prohibited character, but
add a section right after the section on "Prohibited Characters"
explaining the character encoding mechanism and how it should be used to
denote any of the prohibited chars.

Prohibiting the % char in the first place was definitely an oversight on
my part.

Thanks
Drew

>-----Original Message-----
>From: Ken Lassesen [mailto:[hidden email]]
>Sent: Friday, January 25, 2008 11:21 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Ambiguity assigning CPE name to
>product - help please
>
>I agree with Dave, use the %2b.  
>
>-----Original Message-----
>From: Waltermire, Dave [USA] [mailto:[hidden email]]
>Sent: Friday, January 25, 2008 7:31 AM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] Ambiguity assigning CPE name to
>product - help please
>
>Why are we reinventing the wheel here?  URIs allow URL encoding to be
>used for URI reserved characters.  If you need a plus you can use the
>code: %2b.  The advantage of this approach is that in most cases we

can
>use standard URI handling routines to escape/unescape the text
>converting a URI to and from a string representation.  This seems like
>a much more standards based solution.
>
>Dave
>

[Andrew Buttner]

>If the spec is changed to say % isn't prohibited then none of
>the other URI prohibited characters should be listed as
>prohibited.  The spec isn't clear enough about pre v.s. post
>URI encoding.

Agree that the spec is not clear on this.  I will work to correct this.

After reviewing the material you pointed out, I would think a CPE Name
should be post URI encoding.  This is the form that is passed around as
an identifier.  A tool can dereference the URI if it desires, but the
CPE Name would be the fully encoded form.

I always thought of the list of CPE prohibited characters as applying
post-encoding.  In other words, it was a list of characters that should
not appear in the components of the URI that is actually passed around.

>The CPE spec could have a bit more clarity in how the URI
>encoding process happens.

Agree.  I need to enhance the spec to add documentation about this.
What I would like to do is change the Prohibited Characters section to
instead provide a list of chars that must be percent encoded within a
single component.  This list would be the same as the current
prohibited characters list.

Thoughts?

[Mann, Dave]

Mark J Cox wrote:
> Also you can't rely on the version information given by vulnerability
> databases (including CVE/NVD) because they're usually based on third
> party information that is incomplete, inaccurate, or unable to
> predict the future (Entries might state "version 6.4 and earlier are
> vulnerable" but that doesn't mean that the issue actually got fixed
in
>> 6.4, this might be an issue that is as yet unfixed at the time of
>> CVE entry).

Amen, amen, amen!!!

In fact, there is *no* definitive, canonical relationship
between CVEs and CPEs.  There are very particularly defined
relationships that may have meaning for some (hard to determine)
period of time.  But there is no single relationship between
them that will have the same meaning to all parties in all
circumstances.

-Dave
=================================================================
David Mann   |   CVE & CCE Project   |  The MITRE Corporation
-----------------------------------------------------------------
     e-mail:[hidden email]    |      cell:781.424.6003
=================================================================