support for alternate titles
Gapinski at nasa.gov
Wed Sep 26 08:34:09 UTC 2012
On 09/04/2012 01:55 PM, Gary Gapinski wrote:
> I would like at some later time to discuss a syntax for benchmark
> fragments, an XML Schema or other suitable schema for such, inclusive of
> such issues like variant titles. This would foster more rigor of
> maintenance of individual fragments.
I started looking at this with an eye to using NVDL and have some
initial observations and questions.
I chose RHEL6/input/system/accounts/session.xml as a representative
example fragment (there's probably a better term than "fragment" for
such things, but I don't have one). It contains XCCDF <Group>s,
<Value>s, <Rule>s, proto-OCIL, OVAL references, and other stuff.
I would hope that OVAL checks could eventually reside in the same
document in which they are currently cited: namely, within the fragment
containing the referencing XCCDF.
It appears that the project is currently targeting SCAP version 1.1
(based on the chosen namespace declaration for XCCDF output), thus the
schema versions are XCCDF 1.1.4, OVAL 5.8, OCIL 2.0, CPE 2.2, and CCE 5.
Eventual adoption of SCAP version 1.2 would change this to XCCDF 1.2,
OVAL 5.10, and CPE 2.3.
Would both SCAP versions be simultaneously supported at some later time?
(at the fragment level - obviously, the transformations that assemble
the fragments must choose a single SCAP version for their result, and
that in turn could be derived from the highest SCAP version level found
in the fragments chosen for assembly). Seems like that would be the
case. OVAL's lack of namespace precision for different versions makes
this a bit more complicated in an NVDL environment, but handling that
(multiple OVAL versions with identical namespaces) can be discussed at a
Right off the bat, more explicit namespacing will be required. Things
are currently relative and depend on the eventual transformation to
assign namespace context. This means that fragments such as XCCDF, OVAL,
and OCIL would need an explicit namespace declaration (not on every
element, but at least at the top-level enclosing element) using XML
prefixes or xmlns attributes, ditto embedded XHTML, and another
namespace (one vaguely like
http://fedorahosted.org/scap-security-guide/fragment/1.0) will be needed
for other stuff like variant titles or anything else that is useful but
not strictly XCCDF, OVAL, or OCIL. This other "stuff" is currently
precursors such as <ocil>, <oval>, <ref>, etc., essentially anything
that is not defined strictly as (in) XCCDF, OVAL, or OCIL. This other
stuff will need a schema: i.e., a schema is needed for the structure of
If things are explicitly relegated to their respective namespaces, then
an NVDL description of a fragment seems achievable. This would allow the
subordinate schemata such as XCCDF to be directly applied during
schema-driven editing. An additional one or more schemata would be
needed to describe the fragment itself.
NVDL is by no means essential, just handy. It is certainly possible to
define a novel schema for a fragment that ensures reasonable quality of
the portions that ultimately become XCCDF, OVAL, etc., since those
schemata do not undergo frequent change, and a schema for a fragment is
a necessary item in any case. This is particularly true if the
components of a fragment are represented using more tractable syntaxes
than OCIL and OVAL, such as is currently the case with the proto-OCIL
and -OVAL syntaxes.
In other words, if one chooses to wear the various SCAP hair shirts for
authoring, NVDL provides a way to apply the associated schemata while
editing. No hair shirts, no need for NVDL.
Things such as alternate titles require more effort. For example, it's
quite easy to say that a fragment can contain an XCCDF <Rule>, and have
that <Rule> processed according to the XCCDF schema, and easy to say
that the fragment can specify variant <title>s separately from the XCCDF
<Rule> (one of the variants can be presumed to be selected in a
transformation assembly), but it is _not_ so easy to ensure that a
variant <title> can be interpreted in the context of the XCCDF in which
it would ultimately reside - while editing the fragment using a
Less easy than that is ensuring the proper edit-time interpretation of
an XCCDF <sub> in an XHTML portion of some XCCDF prose element which is
cited as a variant value for the prose element. I would hope that such
variations are eschewed, if only because they would occur outside the
context in which they would otherwise afford the application of the
normative schema for that context via NVDL.
In any case, if more rigor is to be obtained for fragment maintenance,
which is somewhat the same as saying schema-driven editing is desirable,
a bit of effort at some later convenient time would be required to
transform the existing fragments into a better-defined and -normed
syntax. If there is some accord on the desirability of this, I'd be
happy to create the necessary examples, transform(s), and schemata.
More information about the scap-security-guide