is <title> used

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

is <title> used

Andrew Buttner
Administrator
>While it is possible to coin unique identifiers for all 7-tuples CPE
>attempts to enumerate, I do not think that is a desirable goal.
>
>It would be useful to enumerate all the things one can say about things
>of interest (vendors, products, versions, etc.), and then be allowed to
>say as many or as few things as one needs to sufficiently establish what
>one is talking about. This is sometimes called a domain, or universe, of
>discourse. Enumerating all valid statements one can utter in such a
>domain is theoretically possible but has limited practical utility.

If I read this right, the proposal here is to stop trying to enumerate all possible platform types, and rather focus on enumerating the individual terms and provide some type of expression mechanism that allows the individual terms to be combined in order to identify the platform type desired.

I think this might be similar in a way to what NIST has been proposing by having the dictionary only contain names with values in all 7 components, thus any other combination could be inferred.

One side effect of this approach is that we would lose the <title> that is meant for a human user.  Remember that the CPE Name is targeted for use by systems behind the scenes, and the title is meant to be displayed to the human user.

** QUESTION **

How important is the <title> for each unique platform type?  Are people using it?  How would just having the CPE Name (and not title) affect you use of CPE?

Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515
Reply | Threaded
Open this post in threaded view
|

Re: is <title> used

Tim Keanini
I hope I understand the discussion correctly.  

There are Annotative properties in RDF/RDFS and thus all the way up the
semantic stack so it is less a question of capability and more of a
question of start-of-authority.

The best-practice is to have the authoritative domain author annotate
resources and classes with the built-in annotative properties
(rdfs:comment, rdfs:seeAlso, rdfs:isDefinedBy, rdfs:label and its
subproperties)

There really does not have to be any loss, it may just be a more
federated method of annotating resources which is not a bad thing.
Goodness gracious, we are even going to have reification and I can't
tell you how happy that make me.  

We should make it a hard requirement that all of the content
functionality that is in the specification today be in the new proposed
formats (at least for some period of time).  This should not be
difficult given that we are embarking on a richer language.

As we tread carefully from XML to RDF and up the stack as need be, we
have to design with the consideration of SPARQL.  It should be assumed
that each domain ontology will see a considerable amount of federation
through SPARQL queries.  

--tk


-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Friday, March 13, 2009 8:34 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] is <title> used

>While it is possible to coin unique identifiers for all 7-tuples CPE
>attempts to enumerate, I do not think that is a desirable goal.
>
>It would be useful to enumerate all the things one can say about things
>of interest (vendors, products, versions, etc.), and then be allowed to
>say as many or as few things as one needs to sufficiently establish
what
>one is talking about. This is sometimes called a domain, or universe,
of
>discourse. Enumerating all valid statements one can utter in such a
>domain is theoretically possible but has limited practical utility.

If I read this right, the proposal here is to stop trying to enumerate
all possible platform types, and rather focus on enumerating the
individual terms and provide some type of expression mechanism that
allows the individual terms to be combined in order to identify the
platform type desired.

I think this might be similar in a way to what NIST has been proposing
by having the dictionary only contain names with values in all 7
components, thus any other combination could be inferred.

One side effect of this approach is that we would lose the <title> that
is meant for a human user.  Remember that the CPE Name is targeted for
use by systems behind the scenes, and the title is meant to be displayed
to the human user.

** QUESTION **

How important is the <title> for each unique platform type?  Are people
using it?  How would just having the CPE Name (and not title) affect you
use of CPE?

Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515
Reply | Threaded
Open this post in threaded view
|

Re: is <title> used

Andrew Buttner
Administrator
I think something subtle is missed here.  If we are inferring certain platform types (maybe through and rdf property) then how would we define a title for that?

For example, if we infer a platform type due to "ACME Product version 1.0 has a professional edition", then which would be the vendor preferred title to be displayed to a user:

ACME Product 1.0 Professional
ACME Product Professional 1.0

I guess I am confused in that if we don't have a specific resource for that specific platform type, then how would we provide a title for it?  An rdf:comment can only be associated with a rdf:resource, right?

Obviously we could have a comment associated with the ACME Product resource, and a comment associated with the Professional Edition resource, and a user could just concat these two comments to come up with a title.  But this might not be the title that software vendor is marketing.

Thanks
Drew




>-----Original Message-----
>From: Tim Keanini [mailto:[hidden email]]
>Sent: Friday, March 13, 2009 11:14 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] is <title> used
>
>I hope I understand the discussion correctly.
>
>There are Annotative properties in RDF/RDFS and thus all the way up the
>semantic stack so it is less a question of capability and more of a
>question of start-of-authority.
>
>The best-practice is to have the authoritative domain author annotate
>resources and classes with the built-in annotative properties
>(rdfs:comment, rdfs:seeAlso, rdfs:isDefinedBy, rdfs:label and its
>subproperties)
>
>There really does not have to be any loss, it may just be a more
>federated method of annotating resources which is not a bad thing.
>Goodness gracious, we are even going to have reification and I can't
>tell you how happy that make me.
>
>We should make it a hard requirement that all of the content
>functionality that is in the specification today be in the new proposed
>formats (at least for some period of time).  This should not be
>difficult given that we are embarking on a richer language.
>
>As we tread carefully from XML to RDF and up the stack as need be, we
>have to design with the consideration of SPARQL.  It should be assumed
>that each domain ontology will see a considerable amount of federation
>through SPARQL queries.
>
>--tk
>
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Friday, March 13, 2009 8:34 AM
>To: [hidden email]
>Subject: [CPE-DISCUSSION-LIST] is <title> used
>
>>While it is possible to coin unique identifiers for all 7-tuples CPE
>>attempts to enumerate, I do not think that is a desirable goal.
>>
>>It would be useful to enumerate all the things one can say about things
>>of interest (vendors, products, versions, etc.), and then be allowed to
>>say as many or as few things as one needs to sufficiently establish
>what
>>one is talking about. This is sometimes called a domain, or universe,
>of
>>discourse. Enumerating all valid statements one can utter in such a
>>domain is theoretically possible but has limited practical utility.
>
>If I read this right, the proposal here is to stop trying to enumerate
>all possible platform types, and rather focus on enumerating the
>individual terms and provide some type of expression mechanism that
>allows the individual terms to be combined in order to identify the
>platform type desired.
>
>I think this might be similar in a way to what NIST has been proposing
>by having the dictionary only contain names with values in all 7
>components, thus any other combination could be inferred.
>
>One side effect of this approach is that we would lose the <title> that
>is meant for a human user.  Remember that the CPE Name is targeted for
>use by systems behind the scenes, and the title is meant to be displayed
>to the human user.
>
>** QUESTION **
>
>How important is the <title> for each unique platform type?  Are people
>using it?  How would just having the CPE Name (and not title) affect you
>use of CPE?
>
>Thanks
>Drew
>
>---------
>
>Andrew Buttner
>The MITRE Corporation
>[hidden email]
>781-271-3515
Reply | Threaded
Open this post in threaded view
|

Re: is <title> used

Gary Gapinski
In reply to this post by Andrew Buttner
Buttner, Drew wrote:

>> While it is possible to coin unique identifiers for all 7-tuples CPE
>> attempts to enumerate, I do not think that is a desirable goal.
>>
>> It would be useful to enumerate all the things one can say about things
>> of interest (vendors, products, versions, etc.), and then be allowed to
>> say as many or as few things as one needs to sufficiently establish what
>> one is talking about. This is sometimes called a domain, or universe, of
>> discourse. Enumerating all valid statements one can utter in such a
>> domain is theoretically possible but has limited practical utility.
>
> If I read this right, the proposal here is to stop trying to enumerate all possible platform types, and rather focus on enumerating the individual terms and provide some type of expression mechanism that allows the individual terms to be combined in order to identify the platform type desired.


More like: eschew enumeration.


>
> I think this might be similar in a way to what NIST has been proposing by having the dictionary only contain names with values in all 7 components, thus any other combination could be inferred.


I don't think so.

Consider, for example, CVE-2008-2364
(http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-2364).

This is a vulnerability with the mod_proxy module in Apache HTTP Server.

There are many things that can be said about this vulnerability.

Apache HTTP Server is a well-known software "product". Sometimes
products are referred to as "applications" (COED: a program that gives a
computer instructions that provide the user with tools to accomplish a
task). "Product" is probably the better of the two. It is not "hardware"
unless it is embedded in a hardware appliance, then maybe it is. Or
isn't. It probably should not be considered an operating system. It
doesn't seem like a platform. Hardware, operating systems, and products
all have applications (COED: practical use or relevance) in the real world.

It is produced by (more properly, under the aegis of) the Apache
Software Foundation. Perhaps its production and concomitant distribution
by the Apache Software Foundation could be considered the act of
"vending", thus making the Apache Software Foundation a "vendor".
Perhaps not. Vendors promote or exchange goods or services for money.

It is distributed by a number of vendors of computer software and
applications. Sometimes as part of an operating system, sometimes as
firmware, sometimes as a component which can be added to an operating
system, sometimes as a sub-component of an application, sometimes
incorporated as a derivative in a larger work, sometimes as a simpler
derivative, and so forth. Sometimes any of the above by entities which
are not vendors of computer software and applications. In any case, the
CVE entry indicates that a number of entities provide this software
thing in a variety of guises.

The CVE contains two CPE identifiers that consider this an
"application", that apache_software_foundation is the "vendor", that
apache_http_server is the "product", and that 2.0.63 and 2.2.8 are the
each a "version". We must have a priori knowledge that
apache_software_foundation is the same as the Apache Software
Foundation, that apache_http_server is the same as the Apache HTTP
Server Project AKA Apache HTTP Server AKA Apache Server AKA Apache httpd
and so forth, and that the two versions denote separate minor versions
of separate major versions ("branches") 2.0 and 2.2, and that (according
to the Apache HTTP Server Project) the vulnerability affects versions
2.2.8, 2.2.6, 2.2.5, 2.2.4, 2.2.3, 2.2.2, and 2.2.0 (the Apache HTTP
Server Project web site curiously lacks references for this
vulnerability in the 2.0 branch).

It is obvious from the CVE that there are many other "platforms" that
exhibit this vulnerability. These appear to require separate CPE
identifiers, and such identifiers will in many cases be difficult to
devise using the triple part:vendor:product, or quadruple
part:vendor:product:version, because in most cases more needs to be said
than can be expressed in a CPE identifier.

It would be handy to be able to say that "Apache HTTP Server 2.0.63 and
2.2.8 and prior versions thereof exhibit a vulnerability" and that
"there are products which contain or are derivatives of Apache HTTP
Server 2.0.63 and 2.2.8" (e.g.,
http://xforce.iss.net/xforce/xfdb/42987), and thus be able to infer that
such products likely exhibit the vulnerability. This of course would
require somegthing more expressive and less constraining than CPE, and
of course would not exhibit the "prefix property", nor most if not all
of the requirements in section 4 of the CPE Specification, for a variety
of reasons.

Platforms, parts, vendors, and products are often the same or similar in
name and meaning. These and their attributes have relationships ranging
from highly specific to quite vague. While some of this information can
be cast within CPE identifiers, I think a richer means of expression is
desirable. Trying to cram much of this into the CPE identifier format
will continue to be problematic. I think unique identifiers will prove
difficult to impossible even for CPE components, much more so for CPE
identifiers.

There are many interesting and useful things that can be said about the
CVE mentioned above, but the SCAP languages chosen thus far do not allow
them to be easily expressed, if at all.