Security labels provide a way of indicating the sensivity of a piece of information, for example e-mail message, document, directory information. They indicate to both the recipient and the associated applications how the information should be handled.
Security Policy Information Files are a way of encapsulating all of the valid security label combinations within a given policy so that security labels can be:
SDN.801 defines any ASN.1 format for describing the security policy, and these have been widely adopted in North American military systems. A number of applications for example, e-mail clients, messaging guards, use these SPIFs.
However there are very few tools around to manage these SPIF files. In addition, X.841 defines a very similar, but not identical, security policy information file.
...
In order to describe a SPIF in an XML document, a appropriate schema needs to be defined which will describe the structure of the XML document.
There are three possible options for developing such a schema
Additions to the ASN.1 standards have provided XML Encoding Rules (XER) which allow ASN.1 objects to be encoded as XML
Further information in XER, including the relevant standards, is available here.
So for example, by taking the X.841 ASN.1 definition of a SPIF, an appropriate schema could be generated.
There is an existing schema definition for a SPIF. It is used by the Visual SPIF program, developed by Cynacom Solutions in 2000, to provide an import/export facility. The program includes the associated DTD1.
The definition is however incomplete and, being a DTD, doesn't provide as rigourous description of SPIF as an XSD.
1If using Internet Explorer, ignore the error message "Cannot have a DTD declaration outside of a DTD.", and just view the source.
A new schema could be developed that exploits the features of the XML Schema Definition language to provide a sophisticated definition of a SPIF. This could include explicit referential integrity checks that are not specifically defined in the ASN.1 definitions.
A new definition could also encompass both SDN.801 and X.841 definitions and additional elements that these standards do not cover (for example, privacy marks, X.411 category definitions).
Whilst each of the options have their merits, it was decided to develop a new schema with a view to encapsulating both SDN.801 and X.841 definitions and also to the use of the XML schema directly, rather than as a textual representation of a SPIF.
A schema was developed to encompass all the elements of SDN.801 and X.841 SPIFs, and provide a schema that would allow editing with even the most basic of XML editorrs. The details of the developed schema are:
| Namespace: | http://www.smhs.co.uk/securitypolicy |
| Location: | http://www.smhs.co.uk/docs/spif/smhssp.xsd |
With this schema, a very simple policy may look like:
<?xml version="1.0" encoding="UTF-8"?>
<sp:SPIF xmlns:sp="http://www.smhs.co.uk/securitypolicy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.smhs.co.uk/securitypolicy http://www.smhs.co.uk/docs/spif/smhssp.xsd"
creationDate="2005021910000Z" rbacId="2.16.840.1.101.2.1.8.1"
originatorDN="o=smhs ltd,c=gb" privilegeId="2.16.840.1.101.2.1.8.2"
keyIdentifier="12345678">
<securityPolicyId id="1.2.3.4" name="Simple"/>
<securityClassification name="Unclassified" lacv="1" hierarchy="1"/>
<securityClassification name="Restricted" lacv="2" hierarchy="2"/>
<securityClassification name="Confidential" lacv="3" hierarchy="3"/>
<securityClassification name="Secret" lacv="4" hierarchy="4"/>
<securityClassification name="Top Secret" lacv="5" hierarchy="5"/>
</sp:SPIF>
This is the current stable version of the schema, though new versions are under development.
Some of the design decisions made when developing the schema are outlined below.
Some of the fields are not fully expanded into the XML Schema and a string encoding is adopted instead. Specifically these are:
A SPIF maintains a lot of internal references, and in the ASN.1 defintions these are maintain through OIDs and integers. Wherever possible within the schema, readable strings have been adopted. For example, excludedClassification identifies a classification name rather than its integer (LACV) value. This allows simple XML editors to be used which can provide a option menu of values with human-readable values rather than integers. This is however at the expense of requiring all classification names to be unique, although this may be seen as beneficial.
The XML schema will also verify that internal references are correct. For example, that an unknown classification cannot be referenced as an exclusion, or that a tag equivalency cannot be made to unknown policy.
Further the schema verifies that values are unique, for example, classifications must have unique LACV values.
Within the ASN.1 definition of a SPIF, there is no way to describe these checks for applications to verify the integrity of the SPIF. However, the schema does not cover all possible referential integrity checks - for example, that a classification allows a category which in turn prohibits the classification.
The schema is still evolving and there are further things that may be incorporated into the schema, including
The General Service (GENSER) Security Policy is a sophisticated security policy that is used within the United States. It has many classifications and categories and relationships between them. It is therefore a good policy with which the exercise the security label schema.
A complete description of the GENSER security policy is available here.
The ASN.1 of the GENSER security policy (although slightly different to that described in the above document) is available from the BAE Systems donwload site, in the Certificate Builder and Test Utilities package.
Using the ASN.1 definition, the following XML instance document was created which describes the security policy: genser.xml
The security policy can be edited by any XML-aware editor, of which there are a wide variety available, many of which are free. These will allow the generation and editing of a compliant XML policy.
Some tools, such as Altova Authentic, another free tool, provide a flexible, custom, interface for editing parts of an XML document.
A simple, example, SPIF editor built with the Authentic plug-in, is available here. (This currently only shows the simple editing of classification values.)
A command line tool, spx2a, allows the conversion between an XML SPIF to an ASN.1 SPIF and vice versa. The supported ASN.1 include SDN.801 and X.841, with SDN.801-style security categories.
It is expected that the XML SPIF will be the master version of the SPIF, with ASN.1 versions being generated being generated for publication. The tool currently generates a new XML SPIF document when converting from ASN.1 and so any additional information about the policy will have to be manually incorporated.
Future versions of spx2a will include merging of the ASN.1 SPIF into a master XML SPIF document, as will as SPIF signing
Other XML schemas already exist for describing SPIFs and XML Stylesheets provide a mechanism to map between the schemas. Stylesheets exist to map the new XML schema to the schema used by VisualSPIF.