software under GPL

[Andrew Buttner]

In looking over some product dictionaries and trying to convert them to
CPE, I keep running across the same scenario and I thought I would ask
the community for their opinions.

The example is a small application that is licensed under GPL,
maintained/written by an individual, but has its own website domain.
How should we write the CPE Name?

A real life example is BusyBox  (http://busybox.net)  BusyBox is
obviously the product name, the question is the vendor piece.  The spec
talks about conflicting options.

One could make the case that we use 'busybox' since this is the
"highest organization-specific label of the organization's DNS name"
(kind of)

Or we could use "denis_vlasenko" since the spec says "For applications
that do not have a vendor associated with them, this component should
use a developer's name."  Of course in this case Denis is the
maintainer and theoretically this could change.

There is no single developer associated with BusyBox.

Should we have a default vendor of "gnu_gpl" for these type of
applications?  (small apps with no vendor that are maintained by a
number of different individuals)

cpe://denis_vlasenko:busybox:1.6.0
cpe://busybox:busybox:1.6.0
cpe://gnu_gpl:busybox:1.6.0

Thoughts?


---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

[Sheldon Malm]

Just a thought - perhaps this is a good opportunity to engage someone like opensource.org to get insight from a different perspective.

--------------------------
Sheldon Malm
Director
Security Research and Development
nCircle VERT

Sent from my BlackBerry Wireless Handheld


----- Original Message -----
From: Buttner, Drew <[hidden email]>
To: [hidden email] <[hidden email]>
Sent: Tue Jun 26 05:56:01 2007
Subject: [CPE-DISCUSSION-LIST] software under GPL

In looking over some product dictionaries and trying to convert them to
CPE, I keep running across the same scenario and I thought I would ask
the community for their opinions.

The example is a small application that is licensed under GPL,
maintained/written by an individual, but has its own website domain.
How should we write the CPE Name?

A real life example is BusyBox  (http://busybox.net)  BusyBox is
obviously the product name, the question is the vendor piece.  The spec
talks about conflicting options.

One could make the case that we use 'busybox' since this is the
"highest organization-specific label of the organization's DNS name"
(kind of)

Or we could use "denis_vlasenko" since the spec says "For applications
that do not have a vendor associated with them, this component should
use a developer's name."  Of course in this case Denis is the
maintainer and theoretically this could change.

There is no single developer associated with BusyBox.

Should we have a default vendor of "gnu_gpl" for these type of
applications?  (small apps with no vendor that are maintained by a
number of different individuals)

cpe://denis_vlasenko:busybox:1.6.0
cpe://busybox:busybox:1.6.0
cpe://gnu_gpl:busybox:1.6.0

Thoughts?


---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

[Lemire, David P.]

Interesting question.  In the case of your specific example, the FAQ page
(which might be out-of-date) actually lists a different name for the
maintainer than does the About page.  Which I think points to a preference
for the product name rather than the developer / maintainer name.  OTOH,
what about projects that exist on, say, SourceForge but don't have their own
website.  Then the "highest organization-specific label of the
organization's DNS name" almost doesn't exist.  And it's not entirely clear
that there's a single consistent answer.  For example, something like
OpenOffice.org or FireFox seems to be a wholely different scale than
something like BusyBox.

So I think I'd lean toward using the product name, if it shows up in a DNS
name, like BusyBox, but otherwise use the gnu_gpl approach, but I'd also
agree that getting input from the open source software community would be a
good idea.  

        Dave
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ David Lemire (Contractor - A&N Associates, Inc.)
~ VAO Engineering and Integration, NSA
~ [hidden email]
~ [phone]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Tuesday, June 26, 2007 8:56 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] software under GPL


In looking over some product dictionaries and trying to convert them to
CPE, I keep running across the same scenario and I thought I would ask
the community for their opinions.

The example is a small application that is licensed under GPL,
maintained/written by an individual, but has its own website domain.
How should we write the CPE Name?

A real life example is BusyBox  (http://busybox.net)  BusyBox is
obviously the product name, the question is the vendor piece.  The spec
talks about conflicting options.

One could make the case that we use 'busybox' since this is the
"highest organization-specific label of the organization's DNS name"
(kind of)

Or we could use "denis_vlasenko" since the spec says "For applications
that do not have a vendor associated with them, this component should
use a developer's name."  Of course in this case Denis is the
maintainer and theoretically this could change.

There is no single developer associated with BusyBox.

Should we have a default vendor of "gnu_gpl" for these type of
applications?  (small apps with no vendor that are maintained by a
number of different individuals)

cpe://denis_vlasenko:busybox:1.6.0
cpe://busybox:busybox:1.6.0
cpe://gnu_gpl:busybox:1.6.0

Thoughts?


---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

[Gary Gapinski-4]

http://osvdb.org/vendor_dict.php is an example of how this might be
accommodated.

[Sheldon Malm]

Some javascript/style in this post has been disabled (why?)

I had to send this out ...




Sheldon Malm
Director
Security Research & Development
nCircle VERT

Check out the VERT daily post
http://blog.ncircle.com/vert



-----Original Message-----
From: Gary Gapinski [[hidden email]]
Sent: Tuesday, June 26, 2007 9:17 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] software under GPL

http://osvdb.org/vendor_dict.php is an example of how this might be accommodated.

[Scott Carpenter-4]

Some javascript/style in this post has been disabled (why?)

Secunia does the same. The real question here is how do we get everyone on the same page. Is the goal of CPE to ensure that all of these sources either use or map back to CPE? Or is it to ensure that CPE maps back to the external sources?

 

http://secunia.com/product/

 

 

From: Sheldon Malm [mailto:[hidden email]]
Sent: Tuesday, June 26, 2007 9:25 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] software under GPL

 

I had to send this out ...




Sheldon Malm
Director
Security Research & Development
nCircle VERT

Check out the VERT daily post
http://blog.ncircle.com/vert



-----Original Message-----
From: Gary Gapinski [[hidden email]]
Sent: Tuesday, June 26, 2007 9:17 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] software under GPL

http://osvdb.org/vendor_dict.php is an example of how this might be accommodated.

[Andrew Buttner]

Thanks for pointing this out Gary.  The welcome text for this vendor
dictionary gives only two options though: legal name listed on web-site
copyright notices OR a person's name.  As pointed, the BusyBox example
seems to just use the product name as the vendor name.

So the question remains, how can we write a specification that creates
a structured way to write these names while making sure that if two
different people try to create a name for the same platform, that they
create the same name.

It seems doable if the application is comes from an established vendor
or if it is written by a single individual.  But we are searching for
ideas for applications written and supported by the open source
community ...

Thanks
Drew

>-----Original Message-----
>From: Gary Gapinski [mailto:[hidden email]]
>Sent: Tuesday, June 26, 2007 9:17 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] software under GPL
>
>http://osvdb.org/vendor_dict.php is an example of how this might be
>accommodated.
>

[Andrew Buttner]

>The real question here is how do we get
>everyone on the same page. Is the goal of CPE to ensure that
>all of these sources either use or map back to CPE? Or is it
>to ensure that CPE maps back to the external sources?


The end goal is for all of these sources to use (or at least maps to)
CPE.  CPE does not want to try and maintain a mapping to many external
sources.  It is only feasible that an external source try to map back
to one common source.

Thanks
Drew

[Noakes, Douglas [USA]]

NVD analysts have taken the approach (recently at least) to use the
product name as the vendor name (rather than proper names).  Having said
that, we haven't always done things this way so there are still quite a
few of these proper names listed as vendors in the cpe dictionary.  I
believe either using the product name as the vendor -or- using a GPL
license tag as the vendor will work just fine, and agree that proper
names should NOT be the vendor (for many reasons).  So, either one of
the following:

cpe://busybox:busybox:1.6.0
cpe://gnu_gpl:busybox:1.6.0

Regardless of what is ultimately decided, some work will need to be done
to clean-up what is currently represented in the cpe dictionary (it can
be done though).

Thank you,
Doug Noakes
NVD Deputy Operations Manager

 

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Tuesday, June 26, 2007 8:56 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] software under GPL

In looking over some product dictionaries and trying to convert them to
CPE, I keep running across the same scenario and I thought I would ask
the community for their opinions.

The example is a small application that is licensed under GPL,
maintained/written by an individual, but has its own website domain.
How should we write the CPE Name?

A real life example is BusyBox  (http://busybox.net)  BusyBox is
obviously the product name, the question is the vendor piece.  The spec
talks about conflicting options.

One could make the case that we use 'busybox' since this is the "highest
organization-specific label of the organization's DNS name"
(kind of)

Or we could use "denis_vlasenko" since the spec says "For applications
that do not have a vendor associated with them, this component should
use a developer's name."  Of course in this case Denis is the maintainer
and theoretically this could change.

There is no single developer associated with BusyBox.

Should we have a default vendor of "gnu_gpl" for these type of
applications?  (small apps with no vendor that are maintained by a
number of different individuals)

cpe://denis_vlasenko:busybox:1.6.0
cpe://busybox:busybox:1.6.0
cpe://gnu_gpl:busybox:1.6.0

Thoughts?


---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

[Kent_Landfield]

Drew,

I agree we need to get a different perspective here.  GPL is a licensing
mechanism. That should *not* get listed as the vendor.  Otherwise what
of the small apps that don't want to use GPL and instead use a BSD
license?

cpe://bsd:busybox:1.6.0 ???

This is flawed. If we are going to need a generic vendor then maybe
something a little more focused on the type of organization it is makes
more sense.

cpe://open_source:busybox:1.6.0

That way you keep the usage accurate, don't confuse licensing
inappropriately and keep the politics away from CPE.

--
Kent Landfield
Director, Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 817.637.8026 Mobile
[hidden email]
www.mcafee.com
 
-----Original Message-----
From: Sheldon Malm [mailto:[hidden email]]
Sent: Tuesday, June 26, 2007 8:00 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] software under GPL

Just a thought - perhaps this is a good opportunity to engage someone
like opensource.org to get insight from a different perspective.

--------------------------
Sheldon Malm
Director
Security Research and Development
nCircle VERT

Sent from my BlackBerry Wireless Handheld


----- Original Message -----
From: Buttner, Drew <[hidden email]>
To: [hidden email]
<[hidden email]>
Sent: Tue Jun 26 05:56:01 2007
Subject: [CPE-DISCUSSION-LIST] software under GPL

In looking over some product dictionaries and trying to convert them to
CPE, I keep running across the same scenario and I thought I would ask
the community for their opinions.

The example is a small application that is licensed under GPL,
maintained/written by an individual, but has its own website domain.
How should we write the CPE Name?

A real life example is BusyBox  (http://busybox.net)  BusyBox is
obviously the product name, the question is the vendor piece.  The spec
talks about conflicting options.

One could make the case that we use 'busybox' since this is the
"highest organization-specific label of the organization's DNS name"
(kind of)

Or we could use "denis_vlasenko" since the spec says "For applications
that do not have a vendor associated with them, this component should
use a developer's name."  Of course in this case Denis is the
maintainer and theoretically this could change.

There is no single developer associated with BusyBox.

Should we have a default vendor of "gnu_gpl" for these type of
applications?  (small apps with no vendor that are maintained by a
number of different individuals)

cpe://denis_vlasenko:busybox:1.6.0
cpe://busybox:busybox:1.6.0
cpe://gnu_gpl:busybox:1.6.0

Thoughts?


---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

[Tim Keanini Sr.]

Some javascript/style in this post has been disabled (why?)

Team,

if you will allow me to think this through on the list, I might offer something to get the creative juices flowing.

IMHO, we must avoid the trap of trying to be meaningful while still achieving the goal of a unique identifier.  We should value being unambiguous over all else.  At the end of this email, I offer a suggestion to decouple these two objectives so that they both can succeed. 

In the current naming scheme, we have these facets: 

vendor:product:version:edition

     a     :      b      :     c      :     d   

Now the problem is that we are perfectly fine when items 'd' (edition), or 'c' (version) change.  The change is appropriate and warrants another identifier.  

cpe://busybox:busybox:1.6.1::

cpe://busybox:busybox:1.6.5:personal:

cpe://busybox:busybox:1.6.5:enterprise:

I'm going to leave 'b' (product) out of the discussion for now because I'm not sure if a company changes a product name without changing the code, does it matter?  Fork this to the background.

Changes however in facet 'a'  are causing us problems because the facet we have chosen can be synonymous to its adjacent facet and offer different levels of specificity.  

In the example below, the set {denic_vlasenko, gnu_gpl, busybox} could be understood to meet the qualification of the vendor facet but offer different levels of specificity and stability (less changing) within that domain.

cpe://denis_vlasenko:busybox:1.6.0::

cpe://gnu_gpl:busybox:1.6.0::

cpe://busybox:busybox:1.6.0::

nCircle just merged with a company called Cambia and renamed the product.   In this example, both 'a' and 'b' facets changed in no meaningful way to a CCE of CVE because no changes were made to facet 'c' or 'd'. 

The edition and version facets possess a directness to CCE and CVE; the vendor (and in rare cases product) grow more and more indirect to CCE and CVE.

This directness quality also stabilized the system because each new identifier is brought in to existence to serve a function.

------------------------------------------------

At the heart of the matter: 

This cpe:/// design forces us to pick facets whereby specificity is always to the extreme right; 

yet we are dealing with changes on the extreme left that may compromise the precision of the facets to the right.

Ideally, facets to the left should be more stable (and as specific as possible)

Could we consider using a numeric for the VENDOR that is referenced in another table?

If we apply that logic to the following example posted by Drew we have a unique '8888' in vendor which brings stability to the entity:

1. cpe://8888:busybox:1.6.0::

2. cpe://8888:busybox:1.6.0::

3. cpe://8888:busybox:1.6.0::

A repository adjacent to NVD would handle the external lookup of 8888 returning meta information like: 

author: denis_vlasenko

license: gnu_gpl

This is just my suggestion.  Ready, aim , fire!

--tk

--

Timothy 'TK' Keanini. CTO

101 Second Street, Suite 400

San Francisco, CA  94105

Office: [phone]

Mobile: [phone]

Fax: [phone]

http://www.ncircle.com/

On Jun 26, 2007, at 7:56 AM, Buttner, Drew wrote:

In looking over some product dictionaries and trying to convert them to

CPE, I keep running across the same scenario and I thought I would ask

the community for their opinions.

The example is a small application that is licensed under GPL,

maintained/written by an individual, but has its own website domain.

How should we write the CPE Name?

A real life example is BusyBox  (http://busybox.net)  BusyBox is

obviously the product name, the question is the vendor piece.  The spec

talks about conflicting options.

One could make the case that we use 'busybox' since this is the

"highest organization-specific label of the organization's DNS name"

(kind of)

Or we could use "denis_vlasenko" since the spec says "For applications

that do not have a vendor associated with them, this component should

use a developer's name."  Of course in this case Denis is the

maintainer and theoretically this could change.

There is no single developer associated with BusyBox.

Should we have a default vendor of "gnu_gpl" for these type of

applications?  (small apps with no vendor that are maintained by a

number of different individuals)

cpe://denis_vlasenko:busybox:1.6.0

cpe://busybox:busybox:1.6.0

cpe://gnu_gpl:busybox:1.6.0

Thoughts?

---------

Andrew Buttner

The MITRE Corporation

[hidden email]

781-271-3515

[Thomas R. Jones]

On Tue, 2007-06-26 at 08:56 -0400, Buttner, Drew wrote:
> In looking over some product dictionaries and trying to convert them to
> CPE, I keep running across the same scenario and I thought I would ask
> the community for their opinions.
>=20
> The example is a small application that is licensed under GPL,
> maintained/written by an individual, but has its own website domain.
> How should we write the CPE Name?

I have a few naming convention proposals, but I will proceed to submit
the proposal relevant to this discussion at this time.

Change the "vendor" identifier to "authority". If you review the URI
specification it even recommends that the authoritative entity be
referenced as such. This disambiguates the CPE reference and removes
any commercial and/or public distinction with regards to the object
being referenced.

As you can see this doesn't retract from the CPE at all, in fact it
reduces inconsistencies with other widely accepted(even government
accepted) standards and specifications.

There are many other small changes that can be made to the CPE to
greatly enhance it's adoption and effectiveness. Maybe I may be able to
communicate with the documentation committee and submit some changes. Or
even construct a mock specification based on my findings/suggestions and su=
bmit for
request for review.

Is the community willing to hear my proposals?=20

Thanks.
Thomas R. Jones

[Thomas R. Jones]

On Tue, 2007-06-26 at 08:56 -0400, Buttner, Drew wrote:
> In looking over some product dictionaries and trying to convert them to
> CPE, I keep running across the same scenario and I thought I would ask
> the community for their opinions.
>
> The example is a small application that is licensed under GPL,
> maintained/written by an individual, but has its own website domain.
> How should we write the CPE Name?

I neglected to add the following submission: if the authority naming
convention is adopted. Then under this instance the authority would be
the individuals name. When an authority is a business entity than as is
legally bound by the entities "articles of organization" --- the
business entity is accepted as an authoritative whole; which would
render the business as the authority.

{C/S} Corporation and Business = common name
LL{C/P} Business = DBA common name
Individual = firstname lastname or firstname middle initial lastname

I think relegating the CPE to domains is a problem. Especially with the
GPL/LGPL community structure. Many individuals such as myself are
contributors to various projects(e.g. cpe, oval) and mapping a product
to a domain is counter-productive. Rather map the product to the
authority. So if the individual makes numerous contributions they all
map back to that individual. If that individual decides to say change
domains then the cpe is unaffected. The individual is still recognized
as the authority for the product regardless of domain membership and all
is good.

Thanks.
Thomas R. Jones

[Andrew Buttner]

Really good points TK.  I think you are right on track with the issue.
Our plan for this was to just branch off a new name when vendors and/or
products change.  (and not going back in time to change existing names)

So in your case you might see:

cpe:///cambia/product_a:1.0
cpe:///cambia/product_a:2.0
cpe:///cambia/product_a:3.0
cpe:///ncircle/product_z:4.0

The loss here is with matching in that if someone want to tag a
statement as applicable to cpe:///ncircle, the previous cambia names
won't match.  But we think the trade-off here with simplicity in
maintaining the names is worth it.  Agree?


As for the numeric id proposal, my one hesitation is that it would
require someone to manage those ids and to assign new ones.  This would
put someone on the critical path.  Our hope was to avoid this by
allowing vendors to 'guess' what their name will be and begin using it
right away.  The CPE Moderator can then add the names to the official
dictionary at their own pace.

But I do agree that technically the generic numeric id solves a number
of technical problems.  Why stop at the vendor though?  It has been
brought up in the past to just have a generic id for the entire
platform, similar to CVE ids.  Along with the maintenance issues, this
also kills the matching application.

Drew

>-----Original Message-----
>From: Tim Keanini Sr. [mailto:[hidden email]]
>Sent: Tuesday, June 26, 2007 11:24 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] software under GPL
>
>Team,
>if you will allow me to think this through on the list, I
>might offer something to get the creative juices flowing.
>
>IMHO, we must avoid the trap of trying to be meaningful while
>still achieving the goal of a unique identifier.  We should
>value being unambiguous over all else.  At the end of this
>email, I offer a suggestion to decouple these two objectives
>so that they both can succeed.
>
>In the current naming scheme, we have these facets:
>vendor:product:version:edition
>     a     :      b      :     c      :     d  
>
>Now the problem is that we are perfectly fine when items 'd'
>(edition), or 'c' (version) change.  The change is appropriate
>and warrants another identifier.  
>cpe://busybox:busybox:1.6.1::
>cpe://busybox:busybox:1.6.5:personal:
>cpe://busybox:busybox:1.6.5:enterprise:
>
>I'm going to leave 'b' (product) out of the discussion for now
>because I'm not sure if a company changes a product name
>without changing the code, does it matter?  Fork this to the
>background.
>
>Changes however in facet 'a'  are causing us problems because
>the facet we have chosen can be synonymous to its adjacent
>facet and offer different levels of specificity.  
>In the example below, the set {denic_vlasenko, gnu_gpl,
>busybox} could be understood to meet the qualification of the
>vendor facet but offer different levels of specificity and
>stability (less changing) within that domain.
>cpe://denis_vlasenko:busybox:1.6.0::
>cpe://gnu_gpl:busybox:1.6.0::
>cpe://busybox:busybox:1.6.0::
>
>nCircle just merged with a company called Cambia and renamed
>the product.   In this example, both 'a' and 'b' facets
>changed in no meaningful way to a CCE of CVE because no
>changes were made to facet 'c' or 'd'.
>
>The edition and version facets possess a directness to CCE and
>CVE; the vendor (and in rare cases product) grow more and more
>indirect to CCE and CVE.
>This directness quality also stabilized the system because
>each new identifier is brought in to existence to serve a function.
>
>------------------------------------------------
>
>At the heart of the matter:
>This cpe:/// design forces us to pick facets whereby
>specificity is always to the extreme right;
>yet we are dealing with changes on the extreme left that may
>compromise the precision of the facets to the right.
>Ideally, facets to the left should be more stable (and as
>specific as possible)
>
>Could we consider using a numeric for the VENDOR that is
>referenced in another table?
>If we apply that logic to the following example posted by Drew
>we have a unique '8888' in vendor which brings stability to the

entity:

>1. cpe://8888:busybox:1.6.0::
>2. cpe://8888:busybox:1.6.0::
>3. cpe://8888:busybox:1.6.0::
>
>A repository adjacent to NVD would handle the external lookup
>of 8888 returning meta information like:
>author: denis_vlasenko
>license: gnu_gpl
>
>This is just my suggestion.  Ready, aim , fire!
>
>--tk
>--
>Timothy 'TK' Keanini. CTO
>
>101 Second Street, Suite 400
>San Francisco, CA  94105
>Office: [phone]
>Mobile: [phone]
>Fax: [phone]
>http://www.ncircle.com/
>
>On Jun 26, 2007, at 7:56 AM, Buttner, Drew wrote:
>
>
> In looking over some product dictionaries and trying to
>convert them to
> CPE, I keep running across the same scenario and I
>thought I would ask
> the community for their opinions.
>
> The example is a small application that is licensed under GPL,
> maintained/written by an individual, but has its own
>website domain.
> How should we write the CPE Name?
>
> A real life example is BusyBox  (http://busybox.net)  BusyBox

is

> obviously the product name, the question is the vendor
>piece.  The spec
> talks about conflicting options.
>
> One could make the case that we use 'busybox' since this is the
> "highest organization-specific label of the
>organization's DNS name"
> (kind of)
>
> Or we could use "denis_vlasenko" since the spec says
>"For applications
> that do not have a vendor associated with them, this
>component should
> use a developer's name."  Of course in this case Denis is the
> maintainer and theoretically this could change.
>
> There is no single developer associated with BusyBox.
>
> Should we have a default vendor of "gnu_gpl" for these type of
> applications?  (small apps with no vendor that are
>maintained by a
> number of different individuals)
>
> cpe://denis_vlasenko:busybox:1.6.0
> cpe://busybox:busybox:1.6.0
> cpe://gnu_gpl:busybox:1.6.0
>
> Thoughts?
>
>
> ---------
>
> Andrew Buttner
> The MITRE Corporation
> [hidden email]
> 781-271-3515
>
>
>
>
>
>

[Andrew Buttner]

>Change the "vendor" identifier to "authority". If you review the URI
>specification it even recommends that the authoritative entity be
>referenced as such. This disambiguates the CPE reference and removes
>any commercial and/or public distinction with regards to the object
>being referenced.

This sounds like an good idea to me.  Helps clear up the terms.  We
still have the BusyBox issue where there is no authority.  But the idea
of having a generic "open_source" authority sounds appealing ...



>Is the community willing to hear my proposals?

absolutely!

[Tim Keanini Sr.]

Some javascript/style in this post has been disabled (why?)

On Jun 26, 2007, at 11:12 AM, Buttner, Drew wrote:

Really good points TK.  I think you are right on track with the issue.

Our plan for this was to just branch off a new name when vendors and/or

products change.  (and not going back in time to change existing names)

So in your case you might see:

cpe:///cambia/product_a:1.0

cpe:///cambia/product_a:2.0

cpe:///cambia/product_a:3.0

cpe:///ncircle/product_z:4.0

The loss here is with matching in that if someone want to tag a

statement as applicable to cpe:///ncircle, the previous cambia names

won't match.  But we think the trade-off here with simplicity in

maintaining the names is worth it.  Agree?

CPE sits at such a fundamental level to other SCAP standards that I do think there is a difference here and a tax to be paid. 

cpe:///cambia/product_a:3.0::

cpe:///ncircle/product_b:3.0::

In this case, for completeness across of other SCAP entities, all the CVE, CCE, and even XCCDF benchmarks associated with cpe:///cambia/product_a:3.0:: will also need to include cpe:///ncircle/product_b:3.0::

It is this ripple effect that can be minimized with the base going to a numeric.  

As for the numeric id proposal, my one hesitation is that it would

require someone to manage those ids and to assign new ones.  This would

put someone on the critical path.  Our hope was to avoid this by

allowing vendors to 'guess' what their name will be and begin using it

right away.  The CPE Moderator can then add the names to the official

dictionary at their own pace.

The dynamic we are going to deal with at first is that it is not the vendors doing the guessing, it is the content analyst or what we should call the librarian.  

I have built enough low-administrative systems to know that it can be done at a low cost.  (MUDs and other online games)

I think that the same administrative budget you are assigning to this CPE moderator would also cover this alternate vendor structure.  

The win is that all content that is going to embed a CPE (XCCDF, CVE, CCE, etc.etc) will benefit from the ultra stable ID even if changes are being made at the level of vendor.  

But I do agree that technically the generic numeric id solves a number

of technical problems.  Why stop at the vendor though?  It has been

brought up in the past to just have a generic id for the entire

platform, similar to CVE ids.  Along with the maintenance issues, this

also kills the matching application.

I'd like to talk about what exactly it is killing.  Maybe there is an alternate way to satisfy these matching objectives?

In any case, I hope this stimulates discussion.  There is nothing worse than a standard that has not gone through hundreds of arguments. :-)

--tk

Drew

-----Original Message-----

From: Tim Keanini Sr. [[hidden email]] 

Sent: Tuesday, June 26, 2007 11:24 AM

To: cpe-discussion-list CPE Community Forum

Subject: Re: [CPE-DISCUSSION-LIST] software under GPL

Team,

if you will allow me to think this through on the list, I 

might offer something to get the creative juices flowing.

IMHO, we must avoid the trap of trying to be meaningful while 

still achieving the goal of a unique identifier.  We should 

value being unambiguous over all else.  At the end of this 

email, I offer a suggestion to decouple these two objectives 

so that they both can succeed. 

In the current naming scheme, we have these facets: 

vendor:product:version:edition

    a     :      b      :     c      :     d   

Now the problem is that we are perfectly fine when items 'd' 

(edition), or 'c' (version) change.  The change is appropriate 

and warrants another identifier.  

cpe://busybox:busybox:1.6.1::

cpe://busybox:busybox:1.6.5:personal:

cpe://busybox:busybox:1.6.5:enterprise:

I'm going to leave 'b' (product) out of the discussion for now 

because I'm not sure if a company changes a product name 

without changing the code, does it matter?  Fork this to the 

background.

Changes however in facet 'a'  are causing us problems because 

the facet we have chosen can be synonymous to its adjacent 

facet and offer different levels of specificity.  

In the example below, the set {denic_vlasenko, gnu_gpl, 

busybox} could be understood to meet the qualification of the 

vendor facet but offer different levels of specificity and 

stability (less changing) within that domain.

cpe://denis_vlasenko:busybox:1.6.0::

cpe://gnu_gpl:busybox:1.6.0::

cpe://busybox:busybox:1.6.0::

nCircle just merged with a company called Cambia and renamed 

the product.   In this example, both 'a' and 'b' facets 

changed in no meaningful way to a CCE of CVE because no 

changes were made to facet 'c' or 'd'. 

The edition and version facets possess a directness to CCE and 

CVE; the vendor (and in rare cases product) grow more and more 

indirect to CCE and CVE.

This directness quality also stabilized the system because 

each new identifier is brought in to existence to serve a function.

------------------------------------------------

At the heart of the matter: 

This cpe:/// design forces us to pick facets whereby 

specificity is always to the extreme right; 

yet we are dealing with changes on the extreme left that may 

compromise the precision of the facets to the right.

Ideally, facets to the left should be more stable (and as 

specific as possible)

Could we consider using a numeric for the VENDOR that is 

referenced in another table?

If we apply that logic to the following example posted by Drew 

we have a unique '8888' in vendor which brings stability to the

entity:

1. cpe://8888:busybox:1.6.0::

2. cpe://8888:busybox:1.6.0::

3. cpe://8888:busybox:1.6.0::

A repository adjacent to NVD would handle the external lookup 

of 8888 returning meta information like: 

author: denis_vlasenko

license: gnu_gpl

This is just my suggestion.  Ready, aim , fire!

--tk

--

Timothy 'TK' Keanini. CTO

101 Second Street, Suite 400

San Francisco, CA  94105

Office: [phone]

Mobile: [phone]

Fax: [phone]

http://www.ncircle.com/

On Jun 26, 2007, at 7:56 AM, Buttner, Drew wrote:

In looking over some product dictionaries and trying to 

convert them to

CPE, I keep running across the same scenario and I 

thought I would ask

the community for their opinions.

The example is a small application that is licensed under GPL,

maintained/written by an individual, but has its own 

website domain.

How should we write the CPE Name?

A real life example is BusyBox  (http://busybox.net)  BusyBox

is

obviously the product name, the question is the vendor 

piece.  The spec

talks about conflicting options.

One could make the case that we use 'busybox' since this is the

"highest organization-specific label of the 

organization's DNS name"

(kind of)

Or we could use "denis_vlasenko" since the spec says 

"For applications

that do not have a vendor associated with them, this 

component should

use a developer's name."  Of course in this case Denis is the

maintainer and theoretically this could change.

There is no single developer associated with BusyBox.

Should we have a default vendor of "gnu_gpl" for these type of

applications?  (small apps with no vendor that are 

maintained by a

number of different individuals)

cpe://denis_vlasenko:busybox:1.6.0

cpe://busybox:busybox:1.6.0

cpe://gnu_gpl:busybox:1.6.0

Thoughts?

---------

Andrew Buttner

The MITRE Corporation

[hidden email]

781-271-3515

--

Timothy 'TK' Keanini. CTO

101 Second Street, Suite 400

San Francisco, CA  94105

Office: [phone]

Mobile: [phone]

Fax: [phone]

http://www.ncircle.com/

Check out our Blog: http://blog.ncircle.com/patterns

[Andrew Buttner]

>>But I do agree that technically the generic numeric id
>>solves a number of technical problems.  Why stop at the
>>vendor though?  It has been brought up in the past to
>>just have a generic id for the entire platform, similar
>>to CVE ids.  Along with the maintenance issues, this
>>also kills the matching application.
>
>
>I'd like to talk about what exactly it is killing.  Maybe
>there is an alternate way to satisfy these matching objectives?

The single id for the entire platform does not allow matching to occur
as the different facets are not broken out.  Any matching would have to
be done by querying some external source.  For example:

cpe:123   =   cpe:///ncircle
cpe:456   =   cpe:///ncircle:product_b:3.0

There is no way for a tool to infer that a platform identified with
cpe:456 satisfies the platform requirements of cpe:123.

[Thomas R. Jones]

On Tue, 2007-06-26 at 12:30 -0400, Buttner, Drew wrote:

> >Change the "vendor" identifier to "authority". If you review the URI
> >specification it even recommends that the authoritative entity be
> >referenced as such. This disambiguates the CPE reference and removes
> >any commercial and/or public distinction with regards to the object
> >being referenced.
>
> This sounds like an good idea to me.  Helps clear up the terms.  We
> still have the BusyBox issue where there is no authority.  But the idea
> of having a generic "open_source" authority sounds appealing ...
>
>

In this instance, I believe it would be adequate to state that the main
developer is Denis Vlasenko. Thus he would be the authoritative entity
associated with the product.
>
> >Is the community willing to hear my proposals?
>
> absolutely!
>
>

[Kent_Landfield]

>> This sounds like an good idea to me.  Helps clear up the terms.  We
>> still have the BusyBox issue where there is no authority.  But the
idea
>> of having a generic "open_source" authority sounds appealing ...
>>
>>
On Tue, 2007-06-26, Thomas wrote:
> In this instance, I believe it would be adequate to state that the
main
> developer is Denis Vlasenko. Thus he would be the authoritative entity
> associated with the product.

I disagree. While it may be adequate, it would not be a good idea. We
want CPE information to be a stable as possible. We do not want to track
changes to authors as open source projects change hands. That occurs
much too often.

--
Kent Landfield
Director, Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 817.637.8026 Mobile
[hidden email]
www.mcafee.com

[Sheldon Malm]

Some javascript/style in this post has been disabled (why?)

I tend to agree with TK on this one ... I think it's important to distinguish human readable format versus machine readable format.  If I understand correctly, one of the primary goals for CPE is to standardize platform naming to enable automation and technology integration.  With a one-to-many relationship between vendor corporate entities and numeric vendor identifiers, we are able to support mergers, acquisitions, and divestitures in a more effective manner.

 

If immediate use is a strong enough driver, there has to be a way to enable self registration that reserves a particular numeric identifier and removes the CPE administrator from the critical path.

 

We went through a similar issue at my former employer, when I converted 80,000 alpha user ID's to numeric names.  There was a short-lived resistance to the change until we were able to implement self-service user access administration within a matter of weeks.  In short, this has already been solved for the most part in the human space with completely abstracted SSN/SIN values, employee numbers, customer numbers, etc.

 

I believe that any overhead on the part of the CPE administrator for managing the vendor corporate name to CPE number relationship would be offset by the elimination of updates to each CPE definition following mergers, acquisitions, or divestitures (provided the one-to-many relationship could be supported).

 

Sheldon Malm
Director
Security Research & Development
nCircle VERT

Check out the VERT daily post
http://blog.ncircle.com/vert

 

 

---

From: Tim Keanini
Sent: Tuesday, June 26, 2007 12:44 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] software under GPL

On Jun 26, 2007, at 11:12 AM, Buttner, Drew wrote:

Really good points TK.  I think you are right on track with the issue.

Our plan for this was to just branch off a new name when vendors and/or

products change.  (and not going back in time to change existing names)

So in your case you might see:

cpe:///cambia/product_a:1.0

cpe:///cambia/product_a:2.0

cpe:///cambia/product_a:3.0

cpe:///ncircle/product_z:4.0

The loss here is with matching in that if someone want to tag a

statement as applicable to cpe:///ncircle, the previous cambia names

won't match.  But we think the trade-off here with simplicity in

maintaining the names is worth it.  Agree?

CPE sits at such a fundamental level to other SCAP standards that I do think there is a difference here and a tax to be paid. 

cpe:///cambia/product_a:3.0::

cpe:///ncircle/product_b:3.0::

In this case, for completeness across of other SCAP entities, all the CVE, CCE, and even XCCDF benchmarks associated with cpe:///cambia/product_a:3.0:: will also need to include cpe:///ncircle/product_b:3.0::

It is this ripple effect that can be minimized with the base going to a numeric.  

As for the numeric id proposal, my one hesitation is that it would

require someone to manage those ids and to assign new ones.  This would

put someone on the critical path.  Our hope was to avoid this by

allowing vendors to 'guess' what their name will be and begin using it

right away.  The CPE Moderator can then add the names to the official

dictionary at their own pace.

The dynamic we are going to deal with at first is that it is not the vendors doing the guessing, it is the content analyst or what we should call the librarian.  

I have built enough low-administrative systems to know that it can be done at a low cost.  (MUDs and other online games)

I think that the same administrative budget you are assigning to this CPE moderator would also cover this alternate vendor structure.  

The win is that all content that is going to embed a CPE (XCCDF, CVE, CCE, etc.etc) will benefit from the ultra stable ID even if changes are being made at the level of vendor.  

But I do agree that technically the generic numeric id solves a number

of technical problems.  Why stop at the vendor though?  It has been

brought up in the past to just have a generic id for the entire

platform, similar to CVE ids.  Along with the maintenance issues, this

also kills the matching application.

I'd like to talk about what exactly it is killing.  Maybe there is an alternate way to satisfy these matching objectives?

In any case, I hope this stimulates discussion.  There is nothing worse than a standard that has not gone through hundreds of arguments. :-)

--tk

Drew

-----Original Message-----

From: Tim Keanini Sr. [[hidden email]] 

Sent: Tuesday, June 26, 2007 11:24 AM

To: cpe-discussion-list CPE Community Forum

Subject: Re: [CPE-DISCUSSION-LIST] software under GPL

Team,

if you will allow me to think this through on the list, I 

might offer something to get the creative juices flowing.

IMHO, we must avoid the trap of trying to be meaningful while 

still achieving the goal of a unique identifier.  We should 

value being unambiguous over all else.  At the end of this 

email, I offer a suggestion to decouple these two objectives 

so that they both can succeed. 

In the current naming scheme, we have these facets: 

vendor:product:version:edition

    a     :      b      :     c      :     d   

Now the problem is that we are perfectly fine when items 'd' 

(edition), or 'c' (version) change.  The change is appropriate 

and warrants another identifier.  

cpe://busybox:busybox:1.6.1::

cpe://busybox:busybox:1.6.5:personal:

cpe://busybox:busybox:1.6.5:enterprise:

I'm going to leave 'b' (product) out of the discussion for now 

because I'm not sure if a company changes a product name 

without changing the code, does it matter?  Fork this to the 

background.

Changes however in facet 'a'  are causing us problems because 

the facet we have chosen can be synonymous to its adjacent 

facet and offer different levels of specificity.  

In the example below, the set {denic_vlasenko, gnu_gpl, 

busybox} could be understood to meet the qualification of the 

vendor facet but offer different levels of specificity and 

stability (less changing) within that domain.

cpe://denis_vlasenko:busybox:1.6.0::

cpe://gnu_gpl:busybox:1.6.0::

cpe://busybox:busybox:1.6.0::

nCircle just merged with a company called Cambia and renamed 

the product.   In this example, both 'a' and 'b' facets 

changed in no meaningful way to a CCE of CVE because no 

changes were made to facet 'c' or 'd'. 

The edition and version facets possess a directness to CCE and 

CVE; the vendor (and in rare cases product) grow more and more 

indirect to CCE and CVE.

This directness quality also stabilized the system because 

each new identifier is brought in to existence to serve a function.

------------------------------------------------

At the heart of the matter: 

This cpe:/// design forces us to pick facets whereby 

specificity is always to the extreme right; 

yet we are dealing with changes on the extreme left that may 

compromise the precision of the facets to the right.

Ideally, facets to the left should be more stable (and as 

specific as possible)

Could we consider using a numeric for the VENDOR that is 

referenced in another table?

If we apply that logic to the following example posted by Drew 

we have a unique '8888' in vendor which brings stability to the

entity:

1. cpe://8888:busybox:1.6.0::

2. cpe://8888:busybox:1.6.0::

3. cpe://8888:busybox:1.6.0::

A repository adjacent to NVD would handle the external lookup 

of 8888 returning meta information like: 

author: denis_vlasenko

license: gnu_gpl

This is just my suggestion.  Ready, aim , fire!

--tk

--

Timothy 'TK' Keanini. CTO

101 Second Street, Suite 400

San Francisco, CA  94105

Office: [phone]

Mobile: [phone]

Fax: [phone]

http://www.ncircle.com/

On Jun 26, 2007, at 7:56 AM, Buttner, Drew wrote:

In looking over some product dictionaries and trying to 

convert them to

CPE, I keep running across the same scenario and I 

thought I would ask

the community for their opinions.

The example is a small application that is licensed under GPL,

maintained/written by an individual, but has its own 

website domain.

How should we write the CPE Name?

A real life example is BusyBox  (http://busybox.net)  BusyBox

is

obviously the product name, the question is the vendor 

piece.  The spec

talks about conflicting options.

One could make the case that we use 'busybox' since this is the

"highest organization-specific label of the 

organization's DNS name"

(kind of)

Or we could use "denis_vlasenko" since the spec says 

"For applications

that do not have a vendor associated with them, this 

component should

use a developer's name."  Of course in this case Denis is the

maintainer and theoretically this could change.

There is no single developer associated with BusyBox.

Should we have a default vendor of "gnu_gpl" for these type of

applications?  (small apps with no vendor that are 

maintained by a

number of different individuals)

cpe://denis_vlasenko:busybox:1.6.0

cpe://busybox:busybox:1.6.0

cpe://gnu_gpl:busybox:1.6.0

Thoughts?

---------

Andrew Buttner

The MITRE Corporation

[hidden email]

781-271-3515

--

Timothy 'TK' Keanini. CTO

101 Second Street, Suite 400

San Francisco, CA  94105

Office: [phone]

Mobile: [phone]

Fax: [phone]

http://www.ncircle.com/

Check out our Blog: http://blog.ncircle.com/patterns