Military Communications and Information Technology: A Trusted ...

446 Military Communications and Information Technology...
may or may not use this key – this depends on the exact trust model tied
to the PKMA.
• If the PKMA mandates the use of certificates, these are included in the signature-element.
Certification information required for delegation are
an exception for this rule (discussed below).
• The schema may make provisions to embrace extensions of a certain PKMA
type, provided they do not exclude other PKMAs from the same function.
In practice, these include:
✓ The block key may be encrypted several times by different public keys,
and these listed independently. The encrypted data blob should not give
preference to any of these.
✓ The role information may be a single identifying string, a list of roles,
or a (propositional) logic expression involving roles, activities and other
restrictions.
C. Design principles: signing
The construction of our CBIS schema follows the principles outlined
in [12], with one major distinction about the signatures. The distinction concerns
the signatory role: whereas in [12] this role was always equated with the key
management center, we implement three different roles: Owner/ADMIN-User,
WRITE-User and Filter. In the structured document itself this is reflected
as content-signatures and metadata signatures, which must thus be independent
of each other.
The trust model used here dictates that the administrative restructuring
of the document should not reveal or modify the actual content, thus the content
and administrative signatures (data vs. metadata) should be independent. However,
in [12] it was not clear how to automatically compute compound signatures for
restructured content with the authority of the Owner. The book suggested using
delegation with attribute certificates.
The work in [5] presents a brilliant solution to retain the compound signatures
constant throughout the whole tree-structure of an XML document. Using this
approach, we are able to keep the content signatures unmodified (by administrative
components).
In addition to the Owner, WRITE-Users are allowed to legally modify the data.
This is accomplished through a list of users with WRITE-permission on an element.
Technically this means that upon opening a document, the User Agent
checks at least the content signatures, and if the signatory is either the Owner
(the only completely trusted party) or another user with WRITE-permissions
listed in the metadata, the signature is accepted as valid.
To enforce the WRITE-permissions list, the whole element containing the list
(cbis:securityAttribute) is signed by an ADMIN-user.