Military Communications and Information Technology: A Trusted ...

450 Military Communications and Information Technology...
Figure 3. Hierarchical conventions of the CBIS schema
If super-encryption would be used, it would also make sense to define access
control lists for the first-order access control information (metadata of metadata,
or meta-metadata). Even in more theoretical work ([12]), the metalevels are recommended
to be restricted to at most two, and we are using only one level.
For versioning purposes, it is not necessary to archive all security metadata.
More specifically, if signatures concern the content as well, they were considered to be
out of scope. Thus we introduce yet another level, cbis:securityAttribute,
which hosts all the data meant to be archived.
The XML-document and architecture model [5] consider only hashes of the elements,
and only the hash of the document whole is eventually signed. Our
model considers a more interactive setting, and allows the document to be more
fine-grained. We then sign each level (certain types of elements) individually, and
the compound sub-documents hierarchically.
V. The CBIS schema
The actual schema is presented here with Fig. 4. for brevity. The Figure depicts
what an XML-formatted CBIS-document would look like, but with element and
type names, enumerations and type definitions.
Legend for Fig. 4 is as follows:
• Multiple labels “behind” the first one indicate that multiple instances are
allowed
• Dashed line round the label indicate a set of optional elements. If there are
multiple dashed-line labels, there can be more than one optional element
• ENUM labels represent XML schema restriction on a specific type
• TYPE labels represents inheritance from another type, depicted the way
a C-language structure would: the parent type is included in the child type