Version 6.0 (Planning)

This page provides information on proposed changes to the OVAL Language. All information about the new version is included in this centralized location. Read the Review Process.

New in Version 6.0

Version 6.0 of the Official OVAL Schema is a direct result of feedback from the OVAL Community. This will be a major version change and may require some new development by tools that support earlier versions of the Language. The changes pending to the different schemas are outlined below. "Open" status means the item is under consideration or being worked upon, "Closed" status means that the item has been incorporated and work on it is completed, and "Suspended" status means that the item will not be included in this version but may be included in a future version.

Items addressed in this version include:

ID Title Status Date Opened Resolution
8701 make it uniform throughout the schema to put references as attributes Open 2006-05-23 n/a
Priority: Medium | Category: n/a | Date Closed: n/a
Details:
While writing OVAL that illustrated the use of the <set> element, I 
noticed the following anomaly in the oval-definitions schema:


<set>
   <object_reference>oval:org.cisecurity:obj:999000</object_reference> 
   <filter>oval:org.cisecurity:ste:999002001</filter>
   <filter>oval:org.cisecurity:ste:999002002</filter>
</set>


Notice the text nodes for the references. Why are these text nodes, when 
everywhere else attributes are used for object and state references?
Follow-ups:
n/a
14134 date/time entities should use the built-in xml date type Open 2008-01-22 n/a
Priority: Medium High | Category: n/a | Date Closed: n/a
Details:
For the Windows file test, the a_time, c_time, and m_time entities should be changed from ints to the built-in xml date/time datatype.
Follow-ups:
Date Added: 2008-04-02 14:16:33
This should not be just limited to the window file test, but all date/time entities should use the built-in xml date type. We should create a new entity type for this.

14938 add attribute supporting order of elements for functions like concat Open 2008-04-03 n/a
Priority: High | Category: Definition Schemas | Date Closed: n/a
Details:
Since order of elements is lost when and XML doc is loaded into a parser, we need to add and ordering attribute to support functions like <concat> where order matters.
Follow-ups:
n/a
16665 add the divide and subtract operations to the arithmetic function Open 2008-08-26 n/a
Priority: Medium | Category: Definition Schemas | Date Closed: n/a
Details:
We need the required position attribute on a component to add these operations in.  The position attribute is scheduled to be added for version 6.0/
Follow-ups:
n/a
14379 add the ability to use xml:lang for comment attributes Open 2008-02-18 n/a
Priority: Very Low | Category: Definition Schemas | Date Closed: n/a
Details:
The scope of xml:lang applies to both the attributes and the content of the element where it appears.  One cannot specify different languages for an attribute and the element content.  Therefore, avoid translatable attributes.

Don't do this:
<Book title="La ma vie et périodes">


Instead, do this:
<Book>
      <Title xml:lang="fr">La ma vie et périodes</Title>


Follow-ups:
Date Added: 2009-05-04 09:52:28
Why can't this be supported in a minor version change?

Date Added: 2009-05-04 11:03:20
The reason this is target for Version 6 is that moving an attribute to an element seems like a significant change to the structure of elements.

Date Added: 2009-05-04 11:05:19
Sorry, i miss read the tracker item. Completely agree that this has to be a version 6 item.

10531 unix files: need enumeration for type, rethink nillable filename Open 2007-01-22 n/a
Priority: Medium | Category: n/a | Date Closed: n/a
Details:
Unix file_state includes a <type> entity, defined as an oval-def:EntityStateStringType.  This effectively does not specify what are the valid values for <type>.  We should enumerate these in a future version of OVAL, so this field can be used effectively.

The schema documentation says:

"This is the file's type: regular file (regular), directory, named pipe (fifo), symbolic link, socket or block special."

The (Solaris) system include file /usr/include/sys/stat.h lists the following types:

#define S_IFIFO         0x1000  /* fifo */
#define S_IFCHR         0x2000  /* character special */
#define S_IFDIR         0x4000  /* directory */
#define S_IFNAM         0x5000  /* XENIX special named file */
#define S_INSEM         0x1     /* XENIX semaphore subtype of IFNAM */
#define S_INSHD         0x2     /* XENIX shared data subtype of IFNAM */
#define S_IFBLK         0x6000  /* block special */
#define S_IFREG         0x8000  /* regular */
#define S_IFLNK         0xA000  /* symbolic link */
#define S_IFSOCK        0xC000  /* socket */
#define S_IFDOOR        0xD000  /* door */

(The XENIX types can probably be ignored.)

We should probably also reconsider whether the <filename> of a file_object should be nillable.  If you want to test whether directory /etc/foo exists, you could have a file_object with path of /etc, filename of foo, and a file_state that checks for type=directory.

Follow-ups:
n/a
9458 introduce a way to leverage content at an external location Open 2006-08-01 n/a
Priority: Medium High | Category: n/a | Date Closed: n/a
Details:
At developer days the following feature was asked for ...

A feature to the language that could help with the relationship between external repositories was discussed.  Currently in version 5.0, any <extended_definition> must reside in the document.  The proposal is to have an <external_definition> that is just a reference to a definition located in some external repository.  The id and location of this definition would be provided so tools can fetch the definition during evaluation.  This allows extension of other's content without forcing the definition writer to pull in all the content they are extending.  Note that XML Includes could be used with the current schema to accomplish something similar.
Follow-ups:
n/a
14428 add an attribute to the entity base type for case sensistivity Open 2008-02-22 n/a
Priority: Very Low | Category: n/a | Date Closed: n/a
Details:
My concern (from SQL Server development experience) is that there will
be proliferation over time of more items (factorial)

I would prefer to see a @sensistivity attribute added instead, this
would consist of a list of up to 4 of the following pairs.

* CI, CS :Case Insensitive
* AI, AS: Accent Insensitive
* KI, KS: Kana Insensitive
* WI, WS: Width Insensitive

Remember -- SQL Server tests are inscope and thus the above may occur in
some cases in the SQL world. We have not seen it --- but "they have
built it, the need will come".

- Ken Lassesen
Follow-ups:
Date Added: 2008-02-22 12:44:13
in version 5.4 we added case insensitive operations. for version 6, should we consider an attribute?

17366 align all test, object, state, and item names Open 2008-10-01 n/a
Priority: Medium High | Category: n/a | Date Closed: n/a
Details:
names should align despite the risk of duplicate constructs being defined in the schema. The upside is a big simplification to the code that associates items and objects and states across the definition schema and the sc schema.
Follow-ups:
Date Added: 2008-10-01 16:06:29
Currently, when a new version of a test is created during minor schema release, the test is given the name <name><version>_test. (eg fileeffectiverights53_test) But the corresponding item in the SC file does not need a new version (entities in the SC are optional) and so the existing item is used. This creates a possible issue where an exact 1:1 mapping between test names and item names does not exist. Is this something that should be corrected? Either by always creating new items or maybe by changing how we create new version of test in a minor release?

Date Added: 2009-05-04 09:58:03
Why is this targeted for version 6? This could be version 5.6 right? it is just adding new items and deprecating old ones right?

Date Added: 2009-05-04 10:58:14
This was targeted for Version 6 since it represents a different test / item relationship. I am also not convinced that this is definetly the correct way to go so I wanted to hold off until a major version to discuss it and think it through.

9664 typo in sedenyremoteInteractivelogonright entity name Open 2006-09-06 n/a
Priority: Low | Category: n/a | Date Closed: n/a
Details:
for both the accesstoken_state (win:def schema) and the accesstoken_item (win:sc schema) there is a typo.  the 'I' in sedenyremoteInteractivelogonright should not be capitalized.
Follow-ups:
n/a
15946 typo in inetlisteningservers_test name Open 2008-07-09 n/a
Priority: Low | Category: n/a | Date Closed: n/a
Details:
One small inconsistency I noticed is that there is an object and state (in the Linux schema) called inetlisteningservers but the item in the SC schema is called inetlisteningserver.
Follow-ups:
Date Added: 2009-05-04 09:59:02
why is this not targeted for version 5.6?

Date Added: 2009-05-04 10:55:05
This is targeted for version 6 since changing the element name (i.e. fixing the typeo) will invalidate existing comment

Date Added: 2009-05-04 10:56:54
Can't we create a new correctly named item in the SC and deprecate the old one? No need to rename anything.

19734 PIXOS line_test doesn't seem to be setup to work off of a single line Open 2009-05-12 n/a
Priority: Medium | Category: Definition Schemas | Date Closed: n/a
Details:
>-----Original Message-----
>From: Matt Woodyard [mailto:matt@MATTWOODYARD.COM]
>Sent: Friday, May 01, 2009 4:18 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: [OVAL-DEVELOPER-LIST] pixos_object
>
>In the pix schema there is a line_object. If one uses the following
>
><line_object><show_subcommand>running-
>config</show_subcommand></line_object>
>
>Should this generate a set of line_items (one for each line of config)
>or one line_item with the entire config in it?
>
>matt




>-----Original Message-----
>From: Buttner, Drew [mailto:abuttner@MITRE.ORG]
>Sent: Tuesday, May 12, 2009 11:12 AM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] pixos_object
>
>I think the way the schema is written that there should be one
><line_item> in the system characteristic file should contain the entire
>config in it.  I agree that the documentation and wording is a bit
>confusing.  We will try to update this with the results of this thread.
>
>Question:  Do the other SHOW commands result in one line from the
>config?
>
>Thanks
>Drew





>-----Original Message-----
>From: Matt Woodyard [mailto:matt@MATTWOODYARD.COM]
>Sent: Tuesday, May 12, 2009 11:31 AM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] pixos_object
>
>I'm not sure what you mean about the other SHOW commands. There are
>plenty of show commands in the PIX/IOS that don't pull lines from the
>config(eg show mac-address-table). They pretty universally produce
>chunks of newline/space delimited text that has some sort of meaning.
>
>My personal preference would be to rework all the cisco (PIX, IOS,etc)
>schemas to have the line_* look like the independent schema
>textfilecontent_*. I find myself wanting to write content for line_tests
>in the same way I would write them for handling a textfilecontent_test.
>
>matt
Follow-ups:
Date Added: 2009-07-09 12:10:32
http://www.cisco.com/en/US/docs/ios/12_1/configfun/command/reference/frd2002.html#wp1019218 Question: For the example used in the webpage above, would the OVAL Object use "running-config" or "show running-confi interface serial 1"

20466 limit the flag entity of the unix-def:interface_state and unix-sc:interface_item to an enumeration Open 2009-07-14 n/a
Priority: Medium | Category: n/a | Date Closed: n/a
Details:
>b) Changing the type of the "flag" entity to be an enumeration of flag
>strings, e.g. (UP, MULTICAST, etc. See /usr/include/net/if.h).
>

I looked at a couple of different unix systems and it seems like this might be a reasonable set to start with:  
    IFF_UP = 0x1,               /* Interface is up.  */
    IFF_BROADCAST = 0x2,        /* Broadcast address valid.  */
    IFF_DEBUG = 0x4,            /* Turn on debugging.  */
    IFF_LOOPBACK = 0x8,         /* Is a loopback net.  */
    IFF_POINTOPOINT = 0x10,     /* Interface is point-to-point link.  */
    IFF_NOTRAILERS = 0x20,      /* Avoid use of trailers.  */
    IFF_RUNNING = 0x40,         /* Resources allocated.  */
    IFF_NOARP = 0x80,           /* No address resolution protocol.  */
    IFF_PROMISC = 0x100,        /* Receive all packets.  */

Are there any concerns with limiting the enumeration in OVAL to just this set?

Given that this is a restriction on the valid data this should probably be a change for the next major version. 
Follow-ups:
n/a
23827 Create enumeration types for certain xinetd_item entities Open 2009-10-14 n/a
Priority: Medium | Category: System Characteristics Schemas | Date Closed: n/a
Details:
The following entities should have enumeration types:

flags: INTERCEPT, NORETRY, IDONLY, NAMEINARGS, NODELAY, KEEPALIVE, NOLIBWRAP, SENSOR, IPv4, IPv6, LABELED, REUSE

socket_type: stream, dgram, raw, seqpacket
Follow-ups:
n/a
24971 typo in security_principle entities Open 2010-02-17 n/a
Priority: Medium | Category: n/a | Date Closed: n/a
Details:
There is a typo in any text that says security_principle.  It should be security_principal.  Please see http://technet.microsoft.com/en-us/library/cc780957(WS.10).aspx for more information.
Follow-ups:
n/a
24134 deprecate win-def:uac_test since uac settings are simply stored in the registry Open 2009-11-17 n/a
Priority: Very Low | Category: Definition Schemas | Date Closed: n/a
Details:
the uac_test is not needed. see:

http://n2.nabble.com/Is-the-win-def-uac-test-Necessary-tp3999228ef20093.html
Follow-ups:
n/a
10567 add schematron rules to ensure values match datatypes Open 2007-01-23 n/a
Priority: Low | Category: Definition Schemas | Date Closed: n/a
Details:
Our current schematron rules won't catch the following:

<registry_state id="oval:org.mitre.oval:ste:500" version="1">
      <value datatype="int">10.0.8326.0</value>
</registry_state>

The value of <value> is clearly not an int.  It would be helpful if we had schematron rules that check the value of an element to make sure it matches the datatype specified.
Follow-ups:
Date Added: 2007-04-18 12:29:10
in version 5.3 added some schematron statements to check that the value is an int when the datatype is set to an int. still need to find a way to do the same for the other datatypes.

26310 make case insensitive equals the default operation for entities that are natively case-insensitive Open 2010-06-04 n/a
Priority: Medium | Category: Definition Schemas | Date Closed: n/a
Details:
>Alternatively, the OVAL windows-definitions-schema.xsd could be 
>modified to define an EntityStateRegistryValueType whose default 
>operation is "case insensitive equals". I think this would most 
>closely match what people would expect to happen when defining 
>registry states. A similar thing could be done for 
>EntityStateRegistryHiveType, EntityStateRegistryKeyType, and 
>EntityStateRegistryNameType. 

I like the suggestion, but I think I would go for just defining something like EntityStateStringIType and EntityObjectStringIType where these entities would have a default operation of "case insensitive equals". These could be used fairly widely in the windows schema. 

However, if we simply created the new schema types and then based the relevant entities on this new type we would be changing the meaning of essentially all windows content, despite the fact that this is a small change to the actual schema. This change would not make existing content fail schema validation, but it would change the meaning of a large portion of the existing content. My inclination is to log this as an issue to address in a major version where it is assumed that we will make changes that will significantly impact existing content. 

Please see the following link for additional information.

http://making-security-measurable.1364806.n2.nabble.com/Windows-case-insensitivity-tp4101606.html
Follow-ups:
n/a
26733 consider using xml namespaces to differentiate revisions to tests within a major version Open 2010-07-06 n/a
Priority: Medium | Category: n/a | Date Closed: n/a
Details:
in the next major release of OVAL we need to consider using xml namespaces to differentiate versions of tests rather than renaming the test with each revision as is the practice in version 5.X
Follow-ups:
n/a
26179 make oval ids compatible with namespaces in xml 1.0 Open 2010-05-25 n/a
Priority: Medium | Category: n/a | Date Closed: n/a
Details:
Has it been brought to anyone's attention that the oval "id" and
"ref_id" attributes are invalid according to Namespaces in XML 1.0[1]? I
ran across this non-conformance while testing for XML Encryption
compatibility.

Here's the relevant statement:

<snip>
No attributes with a declared type of ID, IDREF(S), ENTITY(IES), or
NOTATION contain any colons.
</snip>

Also, I might inject at this time that as of the 2nd Edition of XML
Signature Syntax[2] and Processing that the "xml:id" attribute is the
recommended define for an id attribute. I have tested the oval schemas
and a change would be necessary to accommodate the xml namespace
declaration.

From stdout:
<snip>
Severity: Error
Message: Attribute 'id' should be un-qualified
</snip>

Cheers.
Thomas


[1] http://www.w3.org/TR/REC-xml-names/
[2] http://www.w3.org/TR/xmldsig-core/
Follow-ups:
Date Added: 2010-09-03 10:38:58
The easiest solution I see would be to change the delimiter used in the OVAL id attributes. Use "/" instead of ":".

Date Added: 2010-09-20 10:30:14
Can't use "/", it is not a valid NCName character. How about "-"? http://www.w3.org/TR/REC-xml-names/#NT-NCName

8700 allow the use of filters at the set level instead of just the object reference level Closed 2006-05-23 Fixed
Priority: Very Low | Category: Definition Schemas | Date Closed: 2010-09-21 14:48:30
Details:
It has been mentioned that it would be nice to be able to apply filters to sets instead of just object references.  Could we allow filters in both places?  This would make content writing easier and would eliminate the need for some temporary objects.  With the design in V5, if you want to create a set, and then perform a filter, you have to create a temporary object and then use an object reference in a new set an apply the filter to this.
Follow-ups:
Date Added: 2010-09-21 14:48:30
This feature request has been over come by the addition of filters on objects in version 5.8.

28629 spelling mistake in an entity name in the sol-def:smf_state and the sol-sc:smf_item Open 2010-12-05 n/a
Priority: Medium | Category: n/a | Date Closed: n/a
Details:
The server_arguements entity in the sol-def:smf_state and the sol-sc:smf_item should be changed to server_arguments.
Follow-ups:
n/a
14072 change the epoch entity of rpminfo_test from string to int Open 2008-01-15 n/a
Priority: Medium | Category: n/a | Date Closed: n/a
Details:
From Todd Dolinsky,

I also have a suggestion regarding the current use of the epoch element inside of the rpminfo_object of the linux-definitions-schema.  Currently the epoch is listed as a "string", i.e.

It is my understanding that valid values for the epoch are always integers or the string "(none)".  As the current schema mentions, "(none)" is equivalent to 0, so I would suggest modifying the datatype of the epoch to int from string.  This will of course imply that OVAL authors won't be able to use "(none)" - they'll have to use 0 instead.  The 'pattern match' operation would therefore no longer be allowed.

I think on the whole this seems to make more sense than using comparison operators against strings.
Follow-ups:
Date Added: 2010-08-05 14:52:47
As of version 5.8 the schema documentation will be updated to say that instead of an epoch value of '0' the string '(none)' should be used. In a later major revision the type of this entity should be changed to an int as suggested/ For the time being the impact to content and tools will be to large to justify the change. The documentation change will be included in draft 6 of version 5.8.

Back to top

Timeline for Version 6.0

PLANNING DRAFT RELEASE CANDIDATE OFFICIAL
16 June 2006 TBD TBD TBD
Back to top

Status Reports on Version 6.0

Status updates are included below. You may also review the OVAL Developer’s Forum Archives for discussions about Version 6.0.

[2006-06-16]

Version 6.0 is currently in the planning stage. If you have any suggestions for changes that should be included, please send them to the OVAL Community.

Back to top

Page Last Updated: May 13, 2013