Multiple Editions in Edition Component

[Andrew Buttner]

Based on the recent conversations, I have entered a tracker item regarding adding documentation to the spec about how to handle platform types that are represented by multiple editions.  In other words, how do we fit multiple editions into the Edition component.

Any ideas how this should be handled?  Alphabetical?

Does order really matter?  We could just say that whatever the dictionary says then becomes the correct order.  Note that this would mean we end up with the current set of names that sometimes start with x64 while other end with x64.  But since matching doesn't work within components then is this an issue?

Other thoughts?

Thanks
Drew

---------

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

[Wergin, Charles [USA]]

My thought would be to enter it as it is read.

So in yesterday's example, we had:

OS Name:  Microsoft Windows Vista Home Premium
Version:  6.0.6001 Service Pack 1 Build 6001

Gary submitted:

cpe:/o:microsoft:windows_vista:6.0.6001:sp1:home_premium_x64

I would agree that this would be correct, and should be documented as
such, making the assumption that the 'x64' portion is found in the
System Type and/or Processor line items of the msinfo32 summary.

My question would be, will all tools display it in the same way/order?
That's where it could get messy.

-chuck w.

---------

Chuck Wergin
National Vulnerability Database
nvd.nist.gov

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Thursday, April 16, 2009 9:03 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Multiple Editions in Edition Component

Based on the recent conversations, I have entered a tracker item
regarding adding documentation to the spec about how to handle platform
types that are represented by multiple editions.  In other words, how do
we fit multiple editions into the Edition component.

Any ideas how this should be handled?  Alphabetical?

Does order really matter?  We could just say that whatever the
dictionary says then becomes the correct order.  Note that this would
mean we end up with the current set of names that sometimes start with
x64 while other end with x64.  But since matching doesn't work within
components then is this an issue?

Other thoughts?

Thanks
Drew

---------

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

[Andrew Buttner]

What if a product has two different ways to get summary info that each return product info and the order is different in each one?

>-----Original Message-----
>From: Wergin, Charles [USA] [mailto:[hidden email]]
>Sent: Thursday, April 16, 2009 9:53 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Multiple Editions in Edition
>Component
>
>My thought would be to enter it as it is read.
>
>So in yesterday's example, we had:
>
>OS Name:  Microsoft Windows Vista Home Premium
>Version:  6.0.6001 Service Pack 1 Build 6001
>
>Gary submitted:
>
>cpe:/o:microsoft:windows_vista:6.0.6001:sp1:home_premium_x64
>
>I would agree that this would be correct, and should be documented as
>such, making the assumption that the 'x64' portion is found in the
>System Type and/or Processor line items of the msinfo32 summary.
>
>My question would be, will all tools display it in the same way/order?
>That's where it could get messy.
>
>-chuck w.
>
>---------
>
>Chuck Wergin
>National Vulnerability Database
>nvd.nist.gov
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Thursday, April 16, 2009 9:03 AM
>To: [hidden email]
>Subject: [CPE-DISCUSSION-LIST] Multiple Editions in Edition Component
>
>Based on the recent conversations, I have entered a tracker item
>regarding adding documentation to the spec about how to handle platform
>types that are represented by multiple editions.  In other words, how do
>we fit multiple editions into the Edition component.
>
>Any ideas how this should be handled?  Alphabetical?
>
>Does order really matter?  We could just say that whatever the
>dictionary says then becomes the correct order.  Note that this would
>mean we end up with the current set of names that sometimes start with
>x64 while other end with x64.  But since matching doesn't work within
>components then is this an issue?
>
>Other thoughts?
>
>Thanks
>Drew
>
>---------
>
>Andrew Buttner
>The MITRE Corporation
>[hidden email]
>781-271-3515

[Wergin, Charles [USA]]

Good question.  I'm not familiar with how far we can go with implying
recommended methods of achieving what is accepted into the official
dictionary.  I will have yield to someone with more experience in the
process.


-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Thursday, April 16, 2009 9:56 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Multiple Editions in Edition
Component

What if a product has two different ways to get summary info that each
return product info and the order is different in each one?

>-----Original Message-----
>From: Wergin, Charles [USA] [mailto:[hidden email]]
>Sent: Thursday, April 16, 2009 9:53 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Multiple Editions in Edition
>Component
>
>My thought would be to enter it as it is read.
>
>So in yesterday's example, we had:
>
>OS Name:  Microsoft Windows Vista Home Premium
>Version:  6.0.6001 Service Pack 1 Build 6001
>
>Gary submitted:
>
>cpe:/o:microsoft:windows_vista:6.0.6001:sp1:home_premium_x64
>
>I would agree that this would be correct, and should be documented as
>such, making the assumption that the 'x64' portion is found in the
>System Type and/or Processor line items of the msinfo32 summary.
>
>My question would be, will all tools display it in the same way/order?
>That's where it could get messy.
>
>-chuck w.
>
>---------
>
>Chuck Wergin
>National Vulnerability Database
>nvd.nist.gov
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Thursday, April 16, 2009 9:03 AM
>To: [hidden email]
>Subject: [CPE-DISCUSSION-LIST] Multiple Editions in Edition Component
>
>Based on the recent conversations, I have entered a tracker item
>regarding adding documentation to the spec about how to handle platform
>types that are represented by multiple editions.  In other words, how

do

>we fit multiple editions into the Edition component.
>
>Any ideas how this should be handled?  Alphabetical?
>
>Does order really matter?  We could just say that whatever the
>dictionary says then becomes the correct order.  Note that this would
>mean we end up with the current set of names that sometimes start with
>x64 while other end with x64.  But since matching doesn't work within
>components then is this an issue?
>
>Other thoughts?
>
>Thanks
>Drew
>
>---------
>
>Andrew Buttner
>The MITRE Corporation
>[hidden email]
>781-271-3515

[Gary Newman-2]

I believe that the CPE spec already states that product names should be
identified as named by the manufacturer (as used for marketing).  For some
Windows products, the product edition already has x64 in its name (e.g. Windows
Server 2003 Enterprise x64 Edition) so that should be preserved in the CPE
name.

It only became fuzzier with Vista and Windows Server 2008, where Microsoft
doesn't denote different editions for 64-bit v.s. 32-bit.  With those oses, the
bitness is just an install option.

The recent CPE dictionary has been squeezing the bitness into the edition, for
Vista, which is questionable.  Even more questionable is the use of x32 in
those CPE names, as Microsoft has never referred to its 32-bit versions in that
way.  Before Vista, Microsoft didn't denote bitness of 32-bit oses and used x64
as a marketing term for 64-bit.  With Vista, they switched to not use bitness
in marketing names and in literature refer to "32-bit" and "64-bit".  To
further confuse those techies who'd like to use the "right" technical term,
Windows internally refers to 32-bit oses as x86 and 64-bit oses as AMD64.

Is the 64 v.s. 32 bit version of Vista really a platform identifier?  If so,
should it be another component?

        -Gary-

> Based on the recent conversations, I have entered a tracker item regarding
> adding documentation to the spec about how to handle platform types that are
> represented by multiple editions.  In other words, how do we fit multiple
> editions into the Edition component.
>
> Any ideas how this should be handled?  Alphabetical?
>
> Does order really matter?  We could just say that whatever the dictionary says
> then becomes the correct order.  Note that this would mean we end up with the
> current set of names that sometimes start with x64 while other end with x64.
> But since matching doesn't work within components then is this an issue?
>
> Other thoughts?
>
> Thanks
> Drew
>
> ---------
>
> Andrew Buttner
> The MITRE Corporation
> [hidden email]
> 781-271-3515

[Banghart, John-2]

Gary Newman wrote:
>  
>
> Is the 64 v.s. 32 bit version of Vista really a platform identifier?  If so,
> should it be another component?
>
>  

Gary, I might be misinterpreting your question, so forgive me if I am
(I'm coming late to the discussion).

I think the fact that vulnerabilities could exist on 32-bit Vista but
not 64-bit Vista requires that it be a platform identifier.  Admittedly,
my experience with this problem may seem archaic, but take IPX.  Drivers
exist for Vista, but only 32-bit.  I've also encountered other, older,
software that simply refused to run on 64-bit but ran fine on 32-bit.  
As a result, it seems necessary to draw a distinction between the two,
although I'll grant that the circumstances that make it important are
perhaps rapidly diminishing.

>> Based on the recent conversations, I have entered a tracker item regarding
>> adding documentation to the spec about how to handle platform types that are
>> represented by multiple editions.  In other words, how do we fit multiple
>> editions into the Edition component.
>>
>> Any ideas how this should be handled?  Alphabetical?
>>
>> Does order really matter?  We could just say that whatever the dictionary says
>> then becomes the correct order.  Note that this would mean we end up with the
>> current set of names that sometimes start with x64 while other end with x64.
>> But since matching doesn't work within components then is this an issue?
>>
>> Other thoughts?
>>
>> Thanks
>> Drew
>>
>> ---------
>>
>> Andrew Buttner
>> The MITRE Corporation
>> [hidden email]
>> 781-271-3515
>>    

--
John Banghart
Project Lead, SCAP Validation
National Institute of Standards and Technology
Tel [phone]
[hidden email]

[Gary Newman-2]

Hi John,

Your reasoning is sound, and so to my second question.  If software bitness is
so important shouldn't it have its own component?

I just noticed that the CPE 2.1 spec says "Target hardware and software
environment names will be appended to the end of any other names in the Edition
component."  It seems that the concatenation of edition with the bitness was
the chosen route for this.  Sorry for rehashing this (though I don't recall the
first hashing of it).

As another point in the x32 v.s. x64 bitness naming, the installer for Windows
Server 2008 shows the user two bitness choices labelled x86 and x64.  I haven't
looked recently, but suspect that the Windows Vista installer labels the same
bitness choices as 32-bit and 64-bit.

        -Gary-

> Gary Newman wrote:
> >  
> >
> > Is the 64 v.s. 32 bit version of Vista really a platform identifier?  If so,
> > should it be another component?
> >
> >  
>
> Gary, I might be misinterpreting your question, so forgive me if I am
> (I'm coming late to the discussion).
>
> I think the fact that vulnerabilities could exist on 32-bit Vista but
> not 64-bit Vista requires that it be a platform identifier.  Admittedly,
> my experience with this problem may seem archaic, but take IPX.  Drivers
> exist for Vista, but only 32-bit.  I've also encountered other, older,
> software that simply refused to run on 64-bit but ran fine on 32-bit.  
> As a result, it seems necessary to draw a distinction between the two,
> although I'll grant that the circumstances that make it important are
> perhaps rapidly diminishing.
>
> >> Based on the recent conversations, I have entered a tracker item
> regarding
> >> adding documentation to the spec about how to handle platform types that
> are
> >> represented by multiple editions.  In other words, how do we fit multiple
> >> editions into the Edition component.
> >>
> >> Any ideas how this should be handled?  Alphabetical?
> >>
> >> Does order really matter?  We could just say that whatever the dictionary
> says
> >> then becomes the correct order.  Note that this would mean we end up with
> the
> >> current set of names that sometimes start with x64 while other end with
> x64.
> >> But since matching doesn't work within components then is this an issue?
> >>
> >> Other thoughts?
> >>
> >> Thanks
> >> Drew
> >>
> >> ---------
> >>
> >> Andrew Buttner
> >> The MITRE Corporation
> >> [hidden email]
> >> 781-271-3515
> >>    
>
> --
> John Banghart
> Project Lead, SCAP Validation
> National Institute of Standards and Technology
> Tel [phone]
> [hidden email]
>
>
>

[Banghart, John-2]

I would vote for it having its own component.  To me the bitness isn't  
an edition like "Home Premium" is.  "Home Premium" tells me what  
optional features are available as compared to other editions like  
"Ultimate".  Bitness tells me something fundamental about the OS all  
the way down to the lowest levels.

--
John Banghart
Project Lead, SCAP Validation
National Institute of Standards and Technology
Tel [phone]
[hidden email]


Quoting Gary Newman <[hidden email]>:

> Hi John,
>
> Your reasoning is sound, and so to my second question.  If software  
> bitness is
> so important shouldn't it have its own component?
>
> I just noticed that the CPE 2.1 spec says "Target hardware and software
> environment names will be appended to the end of any other names in  
> the Edition
> component."  It seems that the concatenation of edition with the bitness was
> the chosen route for this.  Sorry for rehashing this (though I don't  
> recall the
> first hashing of it).
>
> As another point in the x32 v.s. x64 bitness naming, the installer  
> for Windows
> Server 2008 shows the user two bitness choices labelled x86 and x64.  
>  I haven't
> looked recently, but suspect that the Windows Vista installer labels the same
> bitness choices as 32-bit and 64-bit.
>
>         -Gary-
>
>> Gary Newman wrote:
>> >
>> >
>> > Is the 64 v.s. 32 bit version of Vista really a platform  
>> identifier?  If so,
>> > should it be another component?
>> >
>> >
>>
>> Gary, I might be misinterpreting your question, so forgive me if I am
>> (I'm coming late to the discussion).
>>
>> I think the fact that vulnerabilities could exist on 32-bit Vista but
>> not 64-bit Vista requires that it be a platform identifier.  Admittedly,
>> my experience with this problem may seem archaic, but take IPX.  Drivers
>> exist for Vista, but only 32-bit.  I've also encountered other, older,
>> software that simply refused to run on 64-bit but ran fine on 32-bit.
>> As a result, it seems necessary to draw a distinction between the two,
>> although I'll grant that the circumstances that make it important are
>> perhaps rapidly diminishing.
>>
>> >> Based on the recent conversations, I have entered a tracker item
>> regarding
>> >> adding documentation to the spec about how to handle platform types that
>> are
>> >> represented by multiple editions.  In other words, how do we fit multiple
>> >> editions into the Edition component.
>> >>
>> >> Any ideas how this should be handled?  Alphabetical?
>> >>
>> >> Does order really matter?  We could just say that whatever the dictionary
>> says
>> >> then becomes the correct order.  Note that this would mean we end up with
>> the
>> >> current set of names that sometimes start with x64 while other end with
>> x64.
>> >> But since matching doesn't work within components then is this an issue?
>> >>
>> >> Other thoughts?
>> >>
>> >> Thanks
>> >> Drew
>> >>
>> >> ---------
>> >>
>> >> Andrew Buttner
>> >> The MITRE Corporation
>> >> [hidden email]
>> >> 781-271-3515
>> >>
>>
>> --
>> John Banghart
>> Project Lead, SCAP Validation
>> National Institute of Standards and Technology
>> Tel [phone]
>> [hidden email]
>>
>>
>>
>

[Wolfkiel, Joseph]

I agree, in concept, with John about breaking out target HW and SW
architecture in future CPE names, but I think the effort and confusion in
trying to deprecate all the existing names and start over, along with the
need to rev the CPE spec again to add one or more new components would be
cost and time prohibitive.

For now, I'm suggesting we just agree that putting the edition + HW + SW
architecture fields in edition doesn't make sense, but we'll just work
around it for a while.  I've asked Drew to look at developing a convention
on how we should populate/order the information in the edition field.

I'd like to have some of this discussion at SCAP developer days,
particularly with respect to when the community thinks we should be looking
at transitioning to CPE 3.0 -- as well as dealing with "bitness" and target
SW environment.


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: John Banghart [mailto:[hidden email]]
Sent: Friday, April 17, 2009 12:17 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Multiple Editions in Edition Component

I would vote for it having its own component.  To me the bitness isn't an
edition like "Home Premium" is.  "Home Premium" tells me what optional
features are available as compared to other editions like "Ultimate".
Bitness tells me something fundamental about the OS all the way down to the
lowest levels.

--
John Banghart
Project Lead, SCAP Validation
National Institute of Standards and Technology Tel [phone]
[hidden email]


Quoting Gary Newman <[hidden email]>:

> Hi John,
>
> Your reasoning is sound, and so to my second question.  If software
> bitness is so important shouldn't it have its own component?
>
> I just noticed that the CPE 2.1 spec says "Target hardware and
> software environment names will be appended to the end of any other
> names in the Edition component."  It seems that the concatenation of
> edition with the bitness was the chosen route for this.  Sorry for
> rehashing this (though I don't recall the first hashing of it).
>
> As another point in the x32 v.s. x64 bitness naming, the installer for
> Windows Server 2008 shows the user two bitness choices labelled x86
> and x64.
>  I haven't
> looked recently, but suspect that the Windows Vista installer labels
> the same bitness choices as 32-bit and 64-bit.
>
>         -Gary-
>
>> Gary Newman wrote:
>> >
>> >
>> > Is the 64 v.s. 32 bit version of Vista really a platform
>> identifier?  If so,
>> > should it be another component?
>> >
>> >
>>
>> Gary, I might be misinterpreting your question, so forgive me if I am
>> (I'm coming late to the discussion).
>>
>> I think the fact that vulnerabilities could exist on 32-bit Vista but
>> not 64-bit Vista requires that it be a platform identifier.  
>> Admittedly, my experience with this problem may seem archaic, but
>> take IPX.  Drivers exist for Vista, but only 32-bit.  I've also
>> encountered other, older, software that simply refused to run on 64-bit

but ran fine on 32-bit.

>> As a result, it seems necessary to draw a distinction between the
>> two, although I'll grant that the circumstances that make it
>> important are perhaps rapidly diminishing.
>>
>> >> Based on the recent conversations, I have entered a tracker item
>> regarding
>> >> adding documentation to the spec about how to handle platform
>> >> types that
>> are
>> >> represented by multiple editions.  In other words, how do we fit
>> >> multiple editions into the Edition component.
>> >>
>> >> Any ideas how this should be handled?  Alphabetical?
>> >>
>> >> Does order really matter?  We could just say that whatever the
>> >> dictionary
>> says
>> >> then becomes the correct order.  Note that this would mean we end
>> >> up with
>> the
>> >> current set of names that sometimes start with x64 while other end
>> >> with
>> x64.
>> >> But since matching doesn't work within components then is this an

issue?

>> >>
>> >> Other thoughts?
>> >>
>> >> Thanks
>> >> Drew
>> >>
>> >> ---------
>> >>
>> >> Andrew Buttner
>> >> The MITRE Corporation
>> >> [hidden email]
>> >> 781-271-3515
>> >>
>>
>> --
>> John Banghart
>> Project Lead, SCAP Validation
>> National Institute of Standards and Technology Tel [phone]
>> [hidden email]
>>
>>
>>
>