Clarification of an Initial Release
|
| 1 2 |
|
In reply to this post
by Wolfkiel, Joseph
|
||||||||
smime.p7m (20K) |
|
Retransmitting for those of you who couldn't read this. 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 410-854-6700 -----Original Message----- From: Wolfkiel, Joseph Sent: Wednesday, November 26, 2008 8:18 AM To: 'CPE Community Forum' Subject: RE: [CPE-DISCUSSION-LIST] Clarification of an Initial Release While I'm not fundamentally opposed to using "_nil_" in this way, it does seem counter-intuitive. My initial take on the "_nil_" identifier was that it would be used to remedy a deficiency in the specification caused by the decision to use blank component names to imply "match everything" versus "blank." In which case, we now have to choose a reserved word to take the place of blank component names (i.e. in cases where the vendor either doesn't use that component in their naming scheme, or didn't populate it for a given software release). With the new logic, we now have the case where "_nil_" = "", "_nil_"="ga", "_nil_"="gold", and the indefinite case of nil="tbd" for any other vendor label inserted to indicate an initial release. One alternative, of course is to just use whatever label has been applied by the vendor. Another might be to choose another reserved word that means "initial release" so that "_nil_" can continue to mean "blank" or "unpopulated." I'm also having some problems coming to grips with the use case that makes the initial release significantly more important to uniquely identify than any subsequent release. Also some issues with the implied business logic. Would "_nil_" only be used in the version field or only in the update field? What would happen if "_nil_" appeared in the language field? Would it imply language general release? What do we do with a vendor who has a product with a "silver", "platinum", and "gold" ?... That said, I'd like to have more feedback from the community on this. 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 410-854-6700 -----Original Message----- From: David Waltermire [mailto:[hidden email]] Sent: Tuesday, November 25, 2008 4:05 PM To: [hidden email] Subject: Re: [CPE-DISCUSSION-LIST] Clarification of an Initial Release Please find my comments inline. I would appreciate any feedback. -----Original Message----- From: Buttner, Drew [mailto:[hidden email]] Sent: Thursday, November 20, 2008 1:36 PM To: [hidden email] Subject: Re: [CPE-DISCUSSION-LIST] Clarification of an Initial Release All, I have been asked to re-open this clarification for further discussion, and set a defined review period before a final decision will be reached. In the rest of this email, I will try to outline the issues at hand and the different views that exist. The discussion will then be open for two weeks. After two weeks, I will either post a new clarification if consensus has been reached, or if consensus was not reached, then I will forward the discussion to our Government sponsors for a decision. Please note that in the near future I will be formalizing this review process and documenting it on the CPE web site. The main issue is explained in the previous email (see the bottom of this email). It deals with which term to use when creating a CPE for an initial release. We often find cases where a given component does not apply to the specific platform type we want to name. We are trying to clarify which term to use. Some options that have been proposed in the past are: ga null no_component blank _nil_ In addition, another aspect of this is whether to use a vendor specific term if one exists, or to always use the term stated above. There have been arguments for using vendor terms when applicable as it makes the CPE Name more understandable by a human user. Having vendor terms can make searching (within an application) for an appropriate CPE easier since one would search with common terms. E.g. a user might not know if Acme Red (IR) would be cpe:/a:acme:red:ir or cpe:/a:acme:red:null. It also makes the process of creating names easier as one simply uses the known terms. Two examples in the current dictionary are: cpe:/o:redhat:enterprise_linux:5:ga cpe:/o:microsoft:windows_2003_server::gold There have also been arguments against using vendor terms. If a non-vendor is creating new CPE Names then that individual will be forced to research the different vendors to know if there is a vendor term or not. Additionally, users that have access to the Official CPE Dictionary can still search for a specific CPE Name by looking at the <title> field. One additional point to consider is that the current CPE Specification (version 2.1) does say in the UPDATE component section to use vendor terms. This has lead to the creation of CPE Names that use vendor terms. The exclusion of vendor terms going forward would force us to either have CPE Names that don't follow the spec (they would still be unique identifiers) or to deprecate those existing names and replace them with new names. Moving forward ... I would love to hear comments from the community on the following two points: 1) What term should be used in a component when creating a new CPE Name in instances where a platform doesn't specify that component (no current edition) or when the platform being described is an initial release and the component may be used to differentiate future releases (an unplanned service pack)? [DW: We need to use a single term consistently. The use of _nil_ seems to be a good candidate. It should not occur in normal use when naming products.] 2) Should vendor terms (e.g. 'ga' or 'gold') be used when appropriate or should the term specified above be used in all cases regardless, even if a different term is commonly used by the vendor? [DW: It is our opinion that _nil_ should replace any vendor term used within the CPE Name where the semantic meaning is the same (e.g. ga, gold, initial, etc.) This will greatly simplify the naming guidance and will result in greater consistency in naming which is a win overall. If this isn't done, it makes naming much more complicated and time consuming than it needs to be. Given that there are thousands of vendors, researching the vendor term for CPE Names that need to be created is not a trivial task. Based on this analysis, I would recommend that we deprecate the old vendor proprietary entries in the near future to keep everything consistent. When the _nil_ approach is used, human-readable titles can be based on the vendor terminology. In fact, this should be encouraged.] Again, this discussion will be open until noon on Thursday December 4th, 2008. Thanks Drew >-----Original Message----- >From: Buttner, Drew [mailto:[hidden email]] >Sent: Saturday, November 15, 2008 7:17 PM >To: cpe-discussion-list CPE Community Forum >Subject: [CPE-DISCUSSION-LIST] Clarification of an Initial Release > >All, > >There has been a lot of talk about how to create CPE Names for initial >releases. This conversation is often had under the notion of a given >platform that does not have a notion of a specific component. For >example, an application that does not support different languages, or >an operating system that does not have updates. > >The issue is that there are some uses within the CPE Community that >need to use CPE Names that do NOT leave that component blank. Remember >that a blank component is used in a CPE Name to identify a platform >type regardless of the value for that component. E.G. an application >CPE Name with a blank edition would represent the platform type for the >application regardless of the edition. Unfortunately we often find >within the industry that an initial release of a platform might not >have editions, but future releases will. Use of the CPE Name with a >blank edition would match both the initial release and any future >releases. The question is how do we create the CPE Name for that >initial release. > >The current CPE Specification (version 2.1) clarifies this point for >the update component and directs us to use a vendor term like 'gold' or >'ga'. Unfortunately, the specification does not say how to handle the >situation when there is no vendor term or for components other than >update. I have been asked to provide some official clarification for >this. Please note that this clarification will be added to any future >version of the specification. > >------------------------------------------------- > >Clarification: > >If attempting to create a CPE Name for a given platform that does not >have or define a certain component, and it is desired to enumerate a >specific release guarding against future releases that may introduce >the component (e.g. the release of a new edition), then the value >'_nil_' should be used. Note that some vendors do in fact define a >term of an initial release but do not use this term in the marketing >name. In these cases, that term should be used instead of '_nil_'. An >example of this is with the Microsoft Windows operating system where >the initial release is known without a service pack. In this case, the >vendor does in fact have a term for this release (gold) and that vendor >term should be used instead of '_nil_'. > >------------------------------------------------- > >I hope this clarifies the issue at hand. Again, this clarification >will be added to any future version of the CPE Specification. Until >that time, I hope this email serves as a reference to help create CPE >Names under version 2.1. I will make sure to post this clarification >to the FAQ section of the CPE web site. > >Thanks >Drew > >--------- > >Andrew Buttner >The MITRE Corporation >[hidden email] >781-271-3515 |
||||||||
|
In reply to this post
by Andrew Buttner
|
||||||||
|
In reply to this post
by Waltermire, David
|
||||||||
|
|
In reply to this post
by Andrew Buttner
|
||||||||
|
|
Once again I would like to thank everyone who shared their opinion regarding the Initial Release issue. The different views were forwarded along to our Government sponsor and a decision has been reached. I'd like to share this decision with the community. Please see the attached document for more information about how the decision was arrived at.
It was decided that a single hyphen (i.e. '-') should be used in any component of a CPE Name when the platform type being enumerated does not have a common value for that component (often found with an initial release), or when given component is not applicable to the platform being enumerated (an application with no editions). For example, for an OS that typically releases updates after an initial release but doesn't give a specific term for that initial release would use '-' in the update component: cpe:/o:vendor:product:1.0:- cpe:/o:vendor:product:1.0:update1 cpe:/o:vendor:product:2.1:-:pro cpe:/o:vendor:product:2.1:update1:pro If a vendor does in fact have a common term for a given component related to an initial release, then the hyphen should not be used to create the CPE Name and the vendor term should be used. We see this with the terms 'gold' for Microsoft and 'ga' for Red Hat. cpe:/a:microsoft:data_access_components:2.5:gold cpe:/o:redhat:enterprise_linux:5:ga The use of a single hyphen was chosen over a term like 'nil' or 'null' since both of those terms imply meaning and could be a source of confusion within the CPE Community. The use of this term is meant for places when no meaning exists (component isn't even applicable or no term is used by the vendor) so a non-word term made the most sense. This clarification to the CPE Specification will be included in the next version (no date has been set). Since this solution does not go against the current version 2.1 of the specification and rather just clarifies how to use the current specification, it should be followed from today forward. Thank you, Drew |
||||||||
|
|
In reply to this post
by Wolfkiel, Joseph
Some javascript/style in this post has been disabled (why?)
Just a reminder that comments on the draft ARF spec are
requested by COB tomorrow. With my apologies for how late they are in the
process, here's the latest versions of the schemas for ARF. Only two major
changes were made (as a result of comments and ongoing dialogue).
First, the CPE-Record now allows for multiple CPE names
to be associated with each installed OS/Application with different confidence
values for each. This functionality allows unauthenticated scanners or
passive sensors to list out the CPE IDs that may correctly describe an installed
app or OS. This is done in lieu of describing ranges or wildcards since
those concepts aren't currently supported by CPE.
Second, an XML representation of X.509 certificates has
been added as an element of the CPE Record so device and person identities
installed on OSs or applications can be reported. Specific elements of the
X.509 certificates that can/must be assessed and reported are still
TBD.
We plan to start comment adjudication on the 18th, so
if you are submitting comments and won't be able to meet the 17th deadline,
please contact me ASAP.
Thanks,
- Joe
Wolfkiel
Lt Col Joseph L.
Wolfkiel |
||||||||
|
|
||||||||
|
|
Some javascript/style in this post has been disabled (why?)
That's a legitimate argument. We've been debating the
value of adding the "any" tag to allow for extensibility. We can, and
probably will, add it to the schemas for the language, though in some DoD
uses, anything appended against the "any" tag will be stripped
off. We did want to ensure the vast majority of required data for SCAP
assessment reporting can be carried in well defined schemas, however we do
acknowledge that there are expected to be cases in the future where users would
want to add additional structured information.
I agree with your points about the web interface. We
will be developing multiple web interfaces against the ARF schemas
and putting this one web service in the spec makes it appear that it
is the only acceptable use. That wasn't the intent. We'll separate
the two in the future.
To all the others on the list who submitted comments:
Thanks. Please don't assume that a lack of immediate answer means we're
ignoring your comments. We have received a lot of comments and will
be going through the process of documenting them and providing an issue-by-issue
comment resolution table so we can track changes to the ARF schemas and web
services back to the originator and comment that drove it. I expect this
process to take as long as a month (possibly a week or so more, given how
near the holidays are).
As for the ARF spec reflecting an internal design spec, it
does--or more accurately, it is an internal design spec that we are releasing to
the public. However the use case we have for SCAP assessment results
exporting, on a per-device basis appears to be fairly common across the
federal government, and (we think) across the private sector as well. Our
long-term intent is to work ARF as a DoD standard for the short term, mostly so
that we can move quickly, then turn it over to NIST to be integrated with CRF
once it is stable and robust enough to meet DoD reporting needs.
Lt Col Joseph L.
Wolfkiel From: Eric Fredericksen [mailto:[hidden email]] Sent: Wednesday, December 17, 2008 6:55 PM To: [hidden email] Subject: Re: [CPE-DISCUSSION-LIST] DoD DRAFT Assessment Results Format for comment -- Unsigned re-transmit of Friday Nov 21, 2008 e-mail I have several
observations.
The specification,
although broad and fairly comprehensive, looks like an externalization of an
internal design document.
The proposal does
not have enough flexibility to be generally useful to us. I suspect the same
goes for most other vendors. By flexibility I mean that that there is no generic
extensibility mechanism for inclusion of arbitrary data in the records. This
problem could of course be remedied by adding
<xsd:anyAttribute namespace="##other" processContents="lax"
/>
and
<xsd:any
minOccurs="0" maxOccurs="unbounded" namespace="##other"
processContents="lax"/>
in the appropriate
locations for each record type.
I understand the
reasons for not doing so - avoiding consumption of potentially malicious data.
However, the resulting specification is therefore not generally useful except as
an export format. The implication is that although this proposal might become a
government requirement it is not looking
like a community standard.
If the proposal
were modified sufficiently to become a community standard the web interface
should be a separate requirement and not part of the data format
specification.
Regards,
Eric
Eric Fredericksen,
PhD This email may contain confidential and privileged information for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies of this message. Thank you. From: Wolfkiel, Joseph [mailto:[hidden email]] Sent: Tuesday, December 16, 2008 4:55 AM To: [hidden email] Subject: Re: [CPE-DISCUSSION-LIST] DoD DRAFT Assessment Results Format for comment -- Unsigned re-transmit of Friday Nov 21, 2008 e-mail Just a reminder that comments on the draft ARF spec are
requested by COB tomorrow. With my apologies for how late they are in the
process, here's the latest versions of the schemas for ARF. Only two major
changes were made (as a result of comments and ongoing dialogue).
First, the CPE-Record now allows for multiple CPE names
to be associated with each installed OS/Application with different confidence
values for each. This functionality allows unauthenticated scanners or
passive sensors to list out the CPE IDs that may correctly describe an installed
app or OS. This is done in lieu of describing ranges or wildcards since
those concepts aren't currently supported by CPE.
Second, an XML representation of X.509 certificates has
been added as an element of the CPE Record so device and person identities
installed on OSs or applications can be reported. Specific elements of the
X.509 certificates that can/must be assessed and reported are still
TBD.
We plan to start comment adjudication on the 18th, so
if you are submitting comments and won't be able to meet the 17th deadline,
please contact me ASAP.
Thanks,
- Joe
Wolfkiel
Lt Col Joseph L.
Wolfkiel |
||||||||
| Free Embeddable Forum Powered by Nabble | Help |
